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iSBC® 552 AND iSXM™ 552 ETHERNET 
COMMUNICATIONS ENGINE PRODUCTS 

MEMBERS OF THE OpenNETTM PRODUCT FAMILY 



I Provides networking capability for all 
IMULTIBUS® systems regardless of t^f 
operating system of the host 

I Supports XENIX*- and RMX-Network 
File Service (XNX-NET and RMX-NET) 
products 

I Available in two versions 
— Turn-key controller implementing 
ISO 8073 Class 4 Standard Transport 
functionality (ISXMtm 552 board) on 
IEEE 802.3 LANs 
r- Flexible, intelligent communications 

controller for ISBC® 552 board for 
i-jufiHftom configurations en IEEE 802.3 

4ans 



ISXMTM 552 board Is fully qualified as 
system extension module for the 
86/310, 286/310, 86/380 and 286/380 
Intel systems 

Resident network software down 
loaded (SXM) or can be stored in on- 
board PROMs (SBC) 

Runs INA 960 and INA 961 (SXM) 
transport software 

On-board 4Ml9i^9tic and boot firmware 
(SXM) 



The iSBC 552 and iSXM 552 COMMengine products are designed for communicatwns front end processor 
applications connecting MULTIBUS systems onto IEEE 802.3/Ethemet LANs. COMMengines are dedicated 
to the communications tasks within a system allowing the host to spend more time processing user applicS' 
tlons. A major advantage of COMMengines is that they can be used to network existing systems and estti^ 
lished designs without forcing the redesign of the entire system architecture. 

The ISBC and iSXM 552 boards can be used with any operating system t)ecause they require only a high level 
interface to communicate with the host (eg. transport commands in case of the ISXM 552 board). The result Is 
a powerful system building block which enables the OEM to connect MULTIBUS-based systems with different 
operating systems to the same network. Applications for the 552 products Include networked multiuser XENIX 
286 based systems for the office and iRMX-based systems for real time applications. The ISXM version Is a 
transport engine complete with on board RAM and ROM memory preconfigured to run iNA 961 transport 
software on-board. INA 961 software Is a version of Intel's INA 960 LAN software implementing the ISO 8073 
Class 4 protocol specially configured to support the ISXM 552 board. The ISBC 552 board is a "de-bundled" 
version of the ISXM 552 board; it comes without memory and software allowing greater flexibility for the user to 
actept the board for his ^>ecial requirmients. 
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The iSBC® Board vs. the ISXMtm 552 

Board 

The fundamental difference between the two ver- 
sions is the ISBC 552 board offers the hardware 
necessary for the user to construct an Ethernet 
front-end processor for his unique requirements and 
the iSXM 552 board provides full ISO starrdard 
transport services ready to plug in and. to to used 
without any additional configuration effort. SXM 
version is aniv«l at i)y populating the iSBC 552 
board with 16K t)ytes of ROMs and 80K bytes of 
iRAMs, and by providing iNA 961 , a directly down- 
loadable transport software module. The iSXM 552 
t>oard is configured for Intel's 86/286-310 systems 
and fully qualified to run in these systems. ISXM 552 
customers receive the iNA software with the pur- 
chase of the INA 961 license «fhl^ is an integral 
part of the SXM offering. 



ARCHITECTURE DESCRIPTION 
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Figure 1 . 

The ISBC and ISXM 552 boards consist of the fol- 
lowing major architectural blocks (see Rgure 1): an 
80186 processor njnning at 6 MHz, the Ethernet I/O 
Channel based on the 82566 LAN coprocessor and 
9m 82501 Ethernet serial interface, the on-board 
memory consisting of ROMs and IRAMs, and the 
MULTIBUS interface. 



Processor 

The iSBC 552 board contains an 80186 processor 
operating in the maximum mode at 6 MHz. It is re- 
sponsible for implementing the intelligent interface 
bistween the ISBC 552 board and a host processor. 
The 80186 processor runs the iNA 961 (iSXM 552) 
and INA 960 (iSBC 552) transport software and de- 
Hvers data between user buffers in MULTIBUS mem- 



ory and iNA960/961 buffers on the ISBC and iSXM 
552 boards. INA 960 and 961 software is responsi- 
ble for the reliable transfer of infomialion tcdoss 
Ethernet. 

The 80186 and 82586 both use asychronous' ready 
logic. The 80186 chip select lines are used to select 
memory mapped I/O locations. 

The 801 86 supplies the timers and the interrupt con- 
troller on iSBC 552. The interrupt controller is used 
in the fully nested mode. The inputs and the outputs 
of the 80186 timers are not connected to external 
sources and destinations. Timer clocking and timer 
interrupts are generated internally in the 80186. 



Memory 

The one megabyte address space of the 80186 is 
divided into four quadrants (see Rgure 2). The first 
(0-256K Byte) and the last (768-1 OOOK Byte) quad- 
rants are reserved for local memory. The second 
quadrant (256-51 2K Byte) is used for memory 
mapped I/O. The iSBC 552 board is totally memory 
mapped. The third quadrant (512-768K Byte) maps 
into a 2S6K Byte MULTIBUS window. This window 
allows the iSBC 552 board to access a total of 16M 
Byte of MULTIBUS memory in 256K Byte segments. 
The iSBC 552 board does not contain any mmiory 
which is acceraible from MULTliBUS. 

The 256K Byte MULTIBUS window starts on 64K 
Byte boundaries anywhere in the 16M byte MULTI- 
BUS memory. The starting location of this window is 
determined by a memory mapped I/O latch de- 
scribed in "ISBC 552 User Interface" section. 

Local memory on the iSBC 552 board (quadrants 
one and four) is made up of twelve 28-pin memory 
sockets. Either EPROM (2764, 27128). Intel IRAM 
(2186) or equivalent static RAM memory can occupy 
these sockets. The only limitations are that the low- 
est pair of sockets corresponding to tfie bottom 
memory location must be RAM and the highest pair 
of sockets corresponding to the top memory loca- 
tion must be EPROM or ROM. The intermediate 
pairs of sockets can be jumper-configured to be ei- 
ther RAM or EPROM. 

Memory mapped I/O locations are selected by the 
PCS and the MCS control lines of the 80186 proces- 
sor. Functions controlled by memory mapped I/O 
are discussed in "iSBC 552 User Interface" secAon. 



Ethernet Interface 

The Ethemet Interface on the ISBC 552 is imple- 
mented ttie 82586 LAN controller and the 82501 
Ethernet Serial Interface. Data is transferred be- 
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tween the on-board memory of the iSBC 552 board 
and the 82566 controller by 82566 Initiated DMA. 
Th9 82586 Initiates the DMA cycles by activating the 
MOiB signal to the 80186 processor. The DMA cy- 
begins when the 80186 processor activgts? the 
W©LD ACKNOWLEDSE signal. 

The 82501 performs Manchester encoding and de- 
coding of the transmit and receive frames. It also 
provides the electrical Interface to the Ethernet 
transceiver cable. 

Each ISBC 552 board is manufactured with a unique 
default 48-bit Ethernet networl< address stored in an 
address PROM. This address PROM is protected by 
checl^sum and can be read by utilizing the on board 
memory mapped I/O. The 82586 can be pro- 
grammed to have this or any other Etherr^t 
address. 



MULTIBUS® Interface 

The ISBC 552 board can access the MULTIBUS with 
an 8- or 1 6-bit data path and can support up to 24- 
address bits. An I/O operation by the 80186 on the 
ISBC 552 board normally accesses the I/O ports on 
the 80186 that controls the processor's interrupt 
controller and timers. MULTIBUS I/O is disabled in 
this normal operation. ISBC 552 MULTIBUS I/O op- 
erations can be enabled or disabled by writing to 
memory mapped I/O control locations (Table 2). 
When the MULTIBUS I/O is enabled, the ISBC 552 
board can write or read the complete 64k bytes of 
I/O space locations. 



Figure 3. @BC« 552 MULTIBUS® 
Conimunlcation Interfaee 



Table 1. 



Value written 
to Flag byte port 


Action 


1 


Resets ISBC 552 b^vd 


2 


Interrupts 80186 on Irltemjpt 




Level 1 


4 


Clears a MULTIBUS interrupt 




previously generated by the 




iSBCraz board 



A host processor in a system communicates with the 
ISBC 552 board via a flag byte port and three other 
byte registers in the MULTIBUS interface. These 
registers are called the "System Configuration Point- 
er" registers (SCP0-SCP2). The flag byte port and 
the SCP registers are presented as 4 consecutive 
MULTIBUS I/O ports to the host processor. The lo- 
cations of these I/O ports on the MULTIBUS are 
configurable on the iSBC 552 (Figure 3). To the 
80186 processor on the ISBC 552 board, the three 
SCP registers are memory mapped locations. 

The flag byte port is used by the host processor to 
reset the iSBC 552 board, to interrupt the 80186 
processor and to reset a MULTIBUS interrupt gener- 
ated by the iSBC 552 board (Table I). SCP0-SCP2 
are general purpose registers that the host proces- 
sor can I/O write to and the iSBC 552 board can 
read from. SCPO can also be preset by hardware 
jumpers. 



ISBC® 552 FUNCTIONAL 
DESCRIPTION 

The ISBC 552 board is a high performance general 
purpose Ethernet COMMenglne, designed to offload 
a host processor in a system from transport layer 
communication processing. The board supports user 
written communications software for unique applica- 
tions or it can run Intel's INA 960 transport software 
in standard applications. When running iNA 960 soft- 
ware, the iSBC 552 board provides the host proces- 
sor with reliable process to process message deliv- 
ery. User messages to be sent are copied by INA 
960 software into iSBC 552 board local memory for 
transmission. Packets received from the network are 
first buffered and reassembled into messages on the 
ISBC 552 board. These re^spe^massages are then 
delivered to the user. 

The ISBC 552 board makes use of the functions on 
the 82586 and 82501 Ethernet controllers to imple- 
ment a number of network functions. These func- 
tions include reprogramming the ISBC 552 station 
address, Multicast packet reception filtering. Time 
Domain Reflectometer t^ts and Loopback diagnos- 
tics. The 82586 also records a number of network 
statistics information, Inforrnation stored include the 
nurriber of CRC and alignment errors, the trnnber of 
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Base I/O port address = configurable. If 8 bit 1/0 is used, base 
port address is configurable from 0-OFCH. If 16 bit I/O is used, 
base port address is configurable from 0-OFFFCH. 
Flag byte: see Table I. 

SCP0-SCP2: I/O written by host processor and read by 60186 
on iSBC and iSXM 552 SCPO can be jumper preset. 
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90MMi@«i Of fi0 i@eeti«@ buffer r^ouRises and ttte 
rmriber eif SlUk #vMinMndsrruns. 

The iSBC 552 can be configured to have a range of 
local memory configurations, from 16K Byte RAM 
(160K Byte EPROM/RCIIi »«l Ipe RAM (16K 
Byte EPROM/ROM). 

The iSBC 552 board and INA 960 software combina- 
tion offers a flexible and configurable transport 
COMMengine, and allows a user to optimally config- 
ure his system for highest performance. The iSXM 
552 and INA 961 combination offers a preconfigured 
turrt-k^ solution. In both cases, iNA 960 software 
and the 552 significantly reduces the design cycle 
bivolved (n dssigntr^ ^ imptctmenSng a transport 
COMMengine. 



iSBC® 552 User Interface 

The iSBC 552 board communicates with a host 
processor through a handshake of interrupts. The 
host processor can generate flag byte interrupts to 
the 80186 on the iSBC 552 and the iSBC 552 can 
generate MULTIBUS interrupts to the host proces- 
sor. The host processor and the iSBC 552 can also 
communicate through shared MULTIBUS system 
memory. None of the on-board buffer on the iSBC 
552 is accessible to the host processor but the ISBC 
552 can read and write all of 16M byte of MULTIBUS 
system memory. 

The host pro@Mi@r aihd the iSBC 552 board further 
communicate through the SCP registers. These byte 
registeis otn be I/O written by the host and can be 
Feat fldisiigh memory rmpp^ I/O by the ISBC 552 



The 80186 processor controls the iSBC 552 through 
memory mapped I/O. Functions that are controlled 
are Med hi Tabte 2. 



OPERATING ENVIRONMENTS 

The iSBC 552 is designed to function in any 
MULTIBUS systems as a communications proces- 
sor. It can function as both a MULTIBUS bus master 
or a slave. As a MULTIBUS master, it can access up 
to 16M byte of host memory and 64K byte of I/O 
address. As a MULTIBUS slave, it occupies four 
consecutive I/O locations on the MULTIBUS. These 
locations are reserved for the flag bytt iMiiltllKW 
SCP registers. 



iSXMTM 552 FUNCTIONMt 
DESCRIPTION 

The iSXM 552 board is a preconfigured iSBC 552 
with 18K Bytes of boot firmware and 80K Bytes of 
iRAM. The iSXM 652 board is offered with INA 961 
preconfigured ISO 8073 transport software. The 
iSXM 552 firmware provides the capabilities to load 
INA 961 onto the 552 from either a buffer in the local 
host or remotely from another Ethernet station. It 
also performs a variety of Ethernet and on-board di- 
agnostics (see sections on iNA 961 User Inter- 
faces and Operating Systems Environment). 

iNA 961 software and the iSXM 552 board together 
provide the functionality of a preconfigured operat- 
ing system independent transport engine. In addition 
to transport services, iNA 961 software also includes 
extensive Data Link and Network Management Fa- 
cility services. Figure 4 shows the configuration of 
INA 961 . Table 3 shows some examples of functions 
provided by INA 961 . INA 961 is a preconfigured ver- 
sion of iNA 960. Refer to the INA 960 data sheet for 
more INA 961 inforrnation. 

User programs that use iNA 960 and the ISBC 
1 86/51 board can be run on a host processor with 
iNA 961 and ISXM 552 as a transport «K|pe. The 
user programs will require minirfial r 
cases. 



Table 2. iSBCo 552 Memory Mapped Functions 



Select Lines 


Read/Write 
by 80186 


Functions 


MCS 


R 


MULTIBUS® Interface registers 

(System Configuration Pointer refflStecs, see s9@MMb# 

e^' > — 




W 

w 
w 

W 
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Channel Attention to 82586 , ^^^^ 
Reading iSBC« 552 Ethernet Address PROMS 
Controlling loopback of 82501 
Disabling and Enabling MULTIBUS* I/O 
Generating and Clearing iSBC^ 552 

interrupts to the MULTIBUS® System Bus 
Controlling the on-board LED 
Latches the MULTIBUS® window segment 
(0 most signiieBnt Wte of 24 bitaddrMs) — ^ i 
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Figure 4. INA 981 CONFIGURATION ON ISXMTM 552 Bowd 



Table 3. INA 961 Services 



Transport 


Virtual circuit 

open: establish a virtueil circuit database 

send connect: actively try to establish a virtual connection 

await connect: passively awaits the arrival of a connection request 

send: send a message 

receive: post a buffer to recove a message 

close: close a virtual circuit 
Datagram 

send: send a datagram message 

receive: post a buffer to receive a datagram message 


Data Link 


Transmit: transmit a data link packet 

Receive: post a buffer to receive a data link packet 

Connect: make a data link logical connection (link 

sen/ice access point, IEEE802.3/802.2) 
Disconnect: disconnect a data link logical connection 
Change Ethernet address: ciiange tlie Ethernet address 
Add multicast address: add a multteast addr^s 
Delete multicast address: remove a multicast address 
Configure 82586: configure the 82586 controller 


Network 
Management 


Read/Clear/Set network objects (local/remote): 

read/clear/set local or remote INA 960 network parameters 
Read/Set network memory (local/remote): 

read/set memory of the local or a remote station. 

Useful in network debug process. 
Boot consumer: requests a network boot server'to 

load a boot file into this station 
Echo: Echo a packet between this statk>n and 

another remote station on Vm network 
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^mni Boot Ftrmware fi^r Interface iNA 961 User Interfaces 



The iSXM 552 boot firmware is used to load iNA 961 
or otiier software onto the 552 from either local 
MULTIBUS memory or a remote network station. 
The firmware performs a number of local and net- 
work diagnostics. Table 4 describes the functions of 
the bootfirnrware. 

The iSXM 552 boot firmware interfaces with the host 
processor through a configurable command buffer 
location in MULTIBUS memory. This location can be 
either jumper or program configured. The host proc- 
essor updates the command byte in the command 
buffer and expects the firmware to update the re- 
sponse 1^ v^ten the command is done. The host 
proeemm ^gn^ to the firmware to examine this 
omwii tiiffB! by writing a 2 to the flag byte port 
Ttie flrmmre vii update the response byte when 
the command is Mr^Mad. 

The iSXM 552 boot firmware commands fully sup- 
port the initialization of the MIP Interface. The MIP 
interface is used by the host processor to communi- 
cate with the INA 961 once it is loaded and started. 
(See section "iNA 961 User Interfaces for" details.) 



User programs give INA 960 commands to the INA 
961 software on the ISXM 552 board via the MULTI- 
BUS Interface Protocol (MIP). MIP is an Intel reliable 
process to process message delivery protocol be- 
tween MULTIBUS processors. Figure 5 illustrates 
how this message delivery functions. Commands are 
passed between the ISXM 552 and the host proces- 
sor in the form of request blocks. A request block is 
a buffer that contains a command specification and 
the command parameters. Each request block (or 
equivalently, each command) is reliably delivered 
from the host processor to INA 961 via the MIP facili- 
ty. INA 961 will extract the command information 
and cany out the command. After a commafMt is 
done, iNA 961 will use the MIP farality to return the 
command result to the user progfam. 

iNA 961 request blocks are in the same formate as 
iNA 960 commands. Refer to the iNA 960 data sljeet 
and reference manuals for more ^M's @n iNA 
software. 



Table 4. ISXMn* S52 BeMtPinnware Commands 


Command 


Function 




This command will indicate that the boot firmware is functional by returning the 
N«Mtaliumber of the firmware, the power on diagnostic result, and tieidiiiWi 
Ethernet address of the iSXM 552. 


l.^>ad 


Load a program from MULTIBUS memory into a de^gnc^ locatiim in the 
iSBC 552 memory. 


Start 


Load a program from MULTIBUS bus memory into a designated location in the 
iSXM 552 memory. Proceed to start this program once it is loaded. This 
command also initialize the MIP interface on the iSXM 552 board. 


Edho 


Echo a packet between this ISXM 5S2 board and another station on #ie 
network. 


Remote Boot 


This command requests a remote boot server station to download software 
onto the iSXM 552. 


and start 
MIP initialize 


Used after a remote boot. This command initializes the MIP interface on the 
iSXM552 and then start the software loaded by the remote boot command. 



Operating SftAmm Envirenimnt 

.'The i^CM 552 board and iNA 961 soHwrare <»m func- 
TSm in any MULTIBUS environmaiL The communi- 
'mSSxjn between the iSXM 552 and the host proces- 
j0or is entireiy independent of any host operating 
= ajstems. iNA 961 uses the MIP protocoi to interface 
--with the host processor. The MIP is a reliable, host 
operating system Independent, process to process 
communication scheme between any processors on 
the MULTIBUS System Bus. iNA 961 can service 
multiple processes utilizing its services at the same 
time. 

A host processor passes iNA 961 commands and 
buffers in the MULTIBUS system memory to the iNA 



961 software. INA 961 is rosponsibie for updating 
the response fields of these commands. It is respon- 
sible for copying flie user send txjfler in MULTIBUS 
system memory Mo its on hoard buffers for trans- 
mission and for copying received messages to user 
buffers in MULTIBUS system memory. 



Diagnostics 

The iSXM 552 board offers a range of power up di- 
agnostics designed to ensure that the 80186 proc- 
essor, the memory (EPROM and iRAM), and the 
Ethernet serial interface are functioning properly. 
Table 5 describes these diagnostics. 
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FIgiire 5. MA 961 MIP RitM-teee 
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ISBC*5S2/eXMW5S2 



Table 5. Functions Checked by 
iSXMTM 552 Diagnostics 



1. Insufficient RAM 

2. Ram matcfi pattern test 

3. Ram ripple data test 

4. Boot firmware PROM checksum 

6. 80186 interrupt controller 

7. 80186 timer controller 

8. 82586 initialization 
9. 82566 CRC check 

10. 82586 broadcast packet recognition 

11. 82586 external loopback 

12. 82586 individufti address recognition 
13. 82586 multteast aUSitrems rSgegnWon 

14. 82586 reset 

1 5. 82586 diagnose check 



DEVELOPMENT ENVIRONMENT 

The SXM 552 board is a turn-key product that al- 
lows a user to emphasize the development of high 
level software, such as a network file server. The 
iSXM 552 board and INA 961 software together form 
a transport COMMengine that integrates into any 
MULTIBUS system. iNA 961 is supplied in a boot 
loadable file format. Tliis file can be loaded into the 
ISXM 552 by a host processor or through a remote 
boot server. The boot firmware on the ISXM 552 
supports both functions. 

The iSBC 552 allows a user to fine tune iNA 960 and 
put the software on the board. Both iNA 960 and the 
iSBC 552 can be flexibly configured to best meet the 
users' requirements. An Intel develophient system, 
together with an Intel I2ICE or equivalent product is 
uSMSHy needed if the user desires to do extensive 
devilment work on the iSBC 552. Intel also sup- 
plies a wide range of host processor boards and sys- 
tems (such as the iSBC 286/10 and system 310) 
that will function well both with the ISBC 552 or the 
iSXM 552. 

INA 960 can be put into PROMs and ain on the iSBC 
552. 



OROCRiNG INFORMATION 

Part Miunber Description 
SXM 552 Ethernet Transport Engine 
SBC 552 Ethernet COMMengine 

SPECIFICATIONS 

Data Transfer Eight or 1 6-bits. 
Average Raw 8.7M bits/ second (450 ns, 16 bit 
MULTIBUS system memory and no 
Transfer Rate MULTIBUS contention) 



TranamtDab 
Rate 

Signal Levels 
Host Intemjpts 

MULTIBUS 
Interface 



Series 10,000 ECL-compatibie. 
One MULTIBUS non-vector 
interrupt for use in^i«te(n/tiest 
handshaking. 

The ISBC 552 board conforms to 
all AC and DC requirements 
outlined in Intel MULTIBUS 
Specification, Order Number 
142686-002m except for the 



Signal ISBC Board MULTIBUS Spec 



DATC- 
DAT7* 



DC Power 
Required 



Environmental 

Temperature 

HumkiHy 



IIH=180)LiA IIH = 125fiA 

All voltages supplied by the 
MULTIBUS interface. 
+ 5.0V ± 5%, 5.9A maximum 
+ 12.0V ±5%, 0.5A maximuni 



0°C to 55°C Operating 
-40°C to 65°C Non-Operaiing 

5% to 90% Operating 
5% to 95% Non-Operating 
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iSBC® 1 86/51 S 
COMMUNICATING COMPUTER 

MEMBER OF THE OpenNETTM PRODUCT FAMILY 



■ 6 MHz lAPX 186 Microprocessor 

■ 128K Bytes of dual-ported RAM 
expandable on-board to 256K Bytes 

■ 82586 Local Communications 
Controller for CSMA/CD applications 
and 82501 Ettiemet serial interface for 
Ethernet/IEEE 802.3 specifications 

■ Two serial interfaces, RS-232C and 
ma2AmSA*S compatible 

• Sockets for up to 192K Bytes of JEOEC 
28 pin standard memory devices 

■ Supports transport layer software 

(iNA 960) and higlier layer communications 
«9ltware (such as RMX-NET) 



■ 80130 Real-Time Operating System 

Firmware 

■ Two iSBX™ bus connectors 

■ 16M Bytes address range of MULTIBUS*' 

■ MULTIBUS® interface for muitimaster 
configurations and system expansion 

■ Supported by a complete family of 
single board computers, periplieral 
controllers, digital & analog I/O, 
memory, padoigiiig and software 



The iSBC® 186/51S COMMUNICATING COMPUTER, the COMMputer™, is a member of Intel's OpenNET family of 
products, and supports Intel's network software. Tfie COMMputer utilizes Intel's VLSI technology to provide an 
economical self-contained computer for applicatons in processing and local area network control. The combination 
of the lAPX 186 Central Processing Unil/80130 Operating System Firmware and the 82586 Local Communications 
Controller/82501 Ethernet Serial Interface makes It ideal for afjplications which require both communication and pro- 
cessing capabilities such as networked workstations, factory automation, office automation, communications 
servers, and many others. The CPU, Ethernet interface, serial comnmjnk»tk}ns interface, 128K Bytes of RAM, up to 
192K Bytes of ROM, Operating System Rmnware, I/O ports and drivers and the MULTIBUS interface all reside on a 
s»n0e 6.75' X 12.00' printed circuit board. 





Intel Corporation Assumes No Responsiblity for the Use of Any Circuitry Other Than Circuitry Embodied in an Intel Product. No Other Circuit 
Patent Licenses are Implied. Infonnation Contained Herein Supercedes Previously Published Specificaiicns On These Devices From Intel. 

©INTEL COPRORATION, 1983. 
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Figure 1v @BC» 186/51 Block Diagram 



FUNCTIONAL DESCRIPTION 

Communicating Computer 

Intel's OpenNET strategy provides the user with 
building blocks to implement all seven layers of the In- 
ternational Standards Organization's (ISO) Open 
Systems Interconnect (OSI) model (see figure 2.) The 
iSBC 186/51S is a part of the OpenNET product family. 
The ISBC 1 86/51 S can host iNA 960 transport layer 
software to provide ISO 8073 class 4 standard protocol 
on IEEE 802.3 LAN. In conjunction with the transport 
file access software, RMX-NET, the ISBC 186/51S and 
INA 960 provide wis^l!tltiflliti^f0^is>/& commtmica- 
tions solution. ' ■ '• '<' 



The iSBC 1 86/51 S board Intergrates a programmable 
processor and communications capability onto one 
board, serving both computational and networking ca- 
pacities as dictated by the application. Tlie communi- 
cations coprocessor (82586) aids In this task by ac- 
complishing as much of the communications task as 
possible before the processor Intervenes (thus reduc- 
ing the overhead k>ad of the 80186 processor). 



"OPEN SYSTEMS" 
ISO MODEL 



NETWORK 
MANAGEMENT 



COMMUNICATION 
APPUCATION 



PRESBmmON 



TRANSPORT 



> RMX'NET 



> iSBC 1851518 



Figure 2. ISBC® 1 86/51 S Impelementation of 
ISO Standard Model 
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iSBC^I 86/51 S 



The dual capabilities of the iSBC 186/51S are useful in 
three types of applications: (1) as a single board com- 
nfiunlcating computer running both user applications 
and communications tasks; (2) as one bus master of a 
multiple processor board solution running a portion of 
the overall user application and the communications 
tasks; and (3) as an "intelligent bus slave" that per- 
forms communications related tasks as a peripheral 
processor to one or more bus masters In a coownunica- 
tions intensive environment. 



iArehttecture 

The iSBC 186/51 S board is functionally partitioned into 
three major sections: central computer, I/O including 
LAN interconnect and memory including shared dual 
port RAM (Figure 1). 

The central computer, with an iAPX 186 CPU and the 
80130 Operating System Firmware (OSF) provides 
powerful processing capability. The microprocessor 
and OSF primitives, together with the on-board 
PROM EPROM sites, programmable timers' 
counters, and programmable interrupt control 
provide the intelligence to manage sophisticated 
communications operations on-board the ISBC 
186/51 S. The timers/counters and interrupt control are 
also common to the I/O area providing programmable 
baud rates to USARTs and prioritizing interrupts 
generated from tfie USARTs. The central computer 
functions are protected for access by the on-board 
SOIfSoniy. 

The I/O is centered around the Ethernet access 
provided by the 82586/82501 pair. All CSMA/CD 
protocols can be supported. Included here as well 
are two serial interfaces, both of which are fully pro- 
grammable. In support of the single board computer, 
two iSBX connectors are provided for further cus- 
tomer expansion of l O capabilities. The I/O is under 
full control of the on-board GPU and is protected from 
access by other system bus masters. 

The third major segment, dual-port RAM memory, is 
the key link between the 80186, the Ethernet control- 
ler, and bus masters (If any) managing the system 
functions. The dual-port concept allows a common 
block of dynamic memory to be accessed by the on- 
board 80186 CPU, the on-board Ethernet controller 
<and off-board bus masters. The system program can, 
therefore, utilize the shared dual-port RAM to pass 
command and status information t>etween the bus 
masters and on-board CPU and Ethernet controllers. 
In addition, the dual-port concept permits blocks of 
data transmitted or received to accummulate in the 
on-board shared RAM, minimizing the need for a 
dedBcMMfniRinory board. 



CENTRAL COMPUTER FUNCTIONALITY 

Central Processing Unit 

The central processor for the ISBC 186/51S is Intel's 
IAPX 186 CPU. The IAPX 186 is a high integration 
1 6-bjt microprocessor. It combines several of the most 
common system components onto the chip (i.e.. 
Direct Memory Access, Interval Timers, Clock gener- 
ator, and Programmable Interrupt Controller) and pro- 
vides a performance improvement of 30% over the 
8086-2 processor The CPU architecture includes four 
16-bit Byte addressable data registers, two 16-bit in- 
dex registers and two 16-bit memory base pointer 
registers. These are accessible by a total of 24 
operand addressing modes for (1) comprehensive 
memory addressing, and (2) support of the data 
structures required for today's structured, high level 
languages — as well as assembly language. 

Instruction Set 

The iAPX 1 86 instruction set is a superset of the 8086. 
It maintains object code compatibility while adding 10 
new instructions to the existing iAPX 86 instruction 
set. The iAPX 186 retains the variable length instruc- 
tion format (including double operand instructions), 
8-bit and 16-bit signed and unsigned arithmetic 
operators for binary, BCD and unpacked ASCII data, 
and Iterative word and byte string manipulations. 
Added instructions include: Block I/O, Enter and 
Leave subroutines. Push Immediate, Multiply Quick, 
Array Bourxls Checking, Shift and Rotate by Immedi- 
ate, and Pop and Push All. 

Arciiitectural Features 

A six-byte instruction queue provides prefetching of 
sequential instructions and can reduce the 750 nsec 
minimum instruction cycle to 250 nsec for queued 
instructions. The stack oriented architecture readily 
supports modular programming by facilitating fast, 
simple, intermodule communication, and other pro- 
gramming constructs needed for asynchronous real- 
time systems. Using a windowing technique and 
external logic, the full 1 6M Bytes addressing range of 
the IEEE-796 MULTIBUS Standard is available to the 
user The dynamic relocation scheme allows ease in 
segmentation of pure procedure and data for efficient 
memory utilization. Four segment registers (code, 
stack, data, extra) contain program loaded offset 
values which are used to map 16-bit addresses to 
20-bit addresses. Each register maps 64K Bytes at a 
time etnd activatk>n of a specific register is controlled, 
both explicitly by program control, and implicitly by 
specific functions and instructions. A flag byte signal- 
ing mechanism aids in creating an interprocessor 
communication scheme. This includes (1 ) the ability to 
set/reset intenupts with MULTIBUS commands and 
(2) board reset. 
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OPERATING SYS? EM FtlNCTIOMALIi» <^ 

Operating System Firmware 

The 80130 provides a set of multitasking kernel 
primitives, kernel control storage, and the additional 
support hardware, including system timers and inter- 
rupt controller, required by those primitives. To the 
applications programmer, the OSF extends the iAPX 
186 architecture by providing 35 operating system 
primitive Instructions, and supporting five new system 
data types. This makes the OSF a logical and easy to 
im mds^emifei i^^m^rr m %e IAPX 186 system 
deagn. Tlie dMp also been designed to be com- 
patible with ttie iHMX86 operating system. 

Arciiitecture 

The 801 30 is connected directly to the local bus of the 
80186 processor with address decoding, buffehng, 
and bus-demultiplexing logic contained on-chip 
(Figure 1). Internally, the 80130 firmware consists of 
two sections: an operating system unit and a control 
unit. The former consists of a 16K Byte operating- 
system-kernel control store complete with an 
operating-system timer, a delay timer, a bit-rate gener- 
ator, and 8259A-compatible programmable interrupt 
logie, - -.'-.^^ — ... 

The first timer generates the fundamental real-time 
clock period in the system. It is set to 10 milliseconds 
inpat^but ewt be i!Re<fiM%#ie system designer. 
TheiiMayttnweuiipMktthslMiel turting function by 
indicating the next event. Bail Wmm tkim«mi6ititSB»' 
are reserved for use by ^l«efi«l. -^ 

The bit-rate generator, which has a range of 75 to 768 

kilobits per second, is provided as a user resource. 
The 80130 interrupt logic vectors eight Independent 
priority levels, one of which is reseryf^.for the, 
operating-sy^em titneOj ■ _pf,., •:^c.ztrn; 



Operation 

The 80130 supplements the 80186's basic architec- 
ture with five new objects, or system data types: jobs, 
tasks, segments, mailboxes, and regions. See Tables 
1 and 2 for the new data types and operating system 
primitives. 



The 80130 operates by creating, man^ulMi^ mi 
deleting individual system otqects. When an Oti^ is 
created, the 801 30 returns Its name to the creating 
task. This name Is referred to and used as an abstract 
data type, called a TOKEN. The TOKEN Is a highly 
efficient way of accessing the iSBC 1 86/51 S address 
space. Referring to a segment object, for example, 
causes a 1 6-bit address to be loaded into one of the 
processor segment registers, which can then be used 
to directly address a paragraph (16-Byte unit) 
anywhere in the ^M Byte address space. Task crea- 
tion is also accomplished in this manner and requires 
only the specification of a priority, a task private data 
segment (if needed), aljBjijglijfc jjW'a te»si< program 
starting address. •'^ " ' "'^ 



To take full advantage of multiprogramming, the oper- 
ating system must provide each application with a 
operate environment — Hiat is, separate memory arid 
tesks. This isolatton tiotti protect Independent pro- 
grams from interfering with one another:»KfaHoi«^4ie 
application programmer to work without regard to We 
other application programs in the system. The 80130 
supports multiprogramming with the job data type. 
The creation of a job requires the specification of a 
large number of parameters and i!| normally done only 
when the system is beti^ mi6am^ 
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Table 1. System Data Types Used in 80130 Operating System FKtnnware 



Job 


Jobs are the means of organizing the program environment and resources. An application 
consists of one or more jobs. Each iAPX 1 86 system data type Is contained In some job. Jobs 
are independent of each other, but they may share access to resources. Each job has one or 
more tasks, one of which Is an Initial tasl<. Jobs are given pools of memory, and they may create 
subordinate offspring jobs, which may borrow memory from their parents. 


Task 


Tasks are the means by which computations are accomplished. A task is an instruction stream 
with its own execution stack and private data. Each task Is part of a job and is restricted to the 
resources provided by its job. Tasks may perform general Interrupt handling as well as other 
computational functions. Each task has a set of attributes, maintained for it by the IAPX 1 86, 
which chEiracterize its status. These attributes are: 

its containing job - ■ 

its register context 

its priority (0-255) 

its execution state (asleep, suspended, ready, running, asleep/suspended) 

its suspension depth 

its user-selected exception handler 

Its option 8087 extended task state 


Segment 


Segments are the units of memory allocation. A segment Is a physically contiguous sequence 
of 16-Byte, 8086 paragraph-length, units. Segments are created dynamically from the free 
memory space of a job as one of Its tasks request memory for Its use. A segment Is deleted 
when It Is no longer needed. The IAPX 1 86 maintains and manages free memory In an orderly 

fashion, it obtains memory space from the pool assigned to the containing job of the requesting 
task and returns the space to the job memory pool (or the parent job pool) when it is no longer 
needed. It does not allocate memory to create a segment if sufficient free memory Is not 
available to it; In that case it returns an error exception code. 


Mailbox 


Mailboxes are the means for intertask communication. Mailboxes are used by tasks to send 
and receive message segments. The IAPX 186 creates and manages two queues for each 
mailbox. One of these queues contains message segments sent to the mailbox but not yet 
received by any task. The other mailbox queue consists of tasks that are waiting to receive 
messages. The IAPX 1 86 assures that waiting tasks receive messages as soon as messages 
are available. Thus at any moment one or possibly both of two mailbox queues will be empty. 


Region 


Regiorts are the means of serialization and mutual exclusion . Regions are familiar as "critical 
code regions.' The iAPX 1 86 region data type consists of a queue of tasks. Each task waits to 
execute in mutually exckislve code or to access a shared data region, for example to update a 
file record. 


Tokens 


The OSF interface makes use of a 16-bit TOKEN data type to identify individual OSF data 
stnjctures. Each of these (each instance) has its own unique TOKEN. When a primitive is 
called, it is passed the TOKENS of the data structures on which it will operate. 
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CREATE JOB 

t 


Creates a job partition including memory pool, ta^ llst^ and stack area. 




CREATE TASK 


Creates a task with the specified environment and priority and puts It in the 
ready state. Checks for insufficient memory available within the containing 

job. 


T 


DELETE TASK 


Deletes a task from the system as well as from any queues in which it is 
waiting. The task's state and stack segment are de-allocated. 


A 

S 
K 


SUSPEND TA^ 


Suspends a task (changes its status to suspended) or increases the task's 
suspension count by 1 . A sleeping task may also be suspended and will 
then awaken suspended unless resumed. 




RESUME TASK 


Decreases the suspension count of a task by 1 . If the count is at that point 
reduced to 0, the task state is made ready or if it was suspend-asleep, It is 
put back to asleep. 




SLEEP 


Puts the task in the asleep state, a number of 10-ms units may be specified. 




SET PRIORITY 


Changes the task's priority to the value passed in the primitive. 




SET INTERRUPT 


Assigns an interrupt handler to a level. The task that makes this call is made 
the interrupt task for the same level, unleSRttWSatt Myites thoe is no 
interrupt task. 




RESET INtERRUPT 


biiSables an intermpt level. Cancels the intern^ handler, deletes the 
interrupt task for that level if assigned. 


1 

N 
T 
E 


GET LEVEL 


Returns the numt)er of the interrupt level for highest priority inter- 
rupt handler currently in opera^on (several interrupt hancttars couki be 

operating). 


EXIT INTERRUPT 


Completes interrupt processing and sends end-of-interrupt signal to 
hardware. 


R 
R 
U 
P 
T 


CI^KIAI IMTCDOI IDT" 

oluNAL IN 1 crtHUrl 


Invokes the Irtierrupt task assigned to a )ifiMl|^p^^^!^ {^leljB^l^jl^rtupt 
handler 


WAIT INTERRUPT 


Makes the interrupt task state suspended pending a signal interrupt from an 
interajpthandtei. Used by an interrupt task to signsliifaiBadiness to senrice 
an interrupt. 




ENABLE 


Enables an external interrupt level. 




DISABLE 


Disables an external interrupt level. 




GET EXCEPTION 
HANDLER 


Reads the location and exception-handling mode of the current operating 
system exception handler for a' task. 




SET EXCEPTION 
, HANDLER 


Establishes the location and exception-handling mode of the current oper- 
- '■ exceptk>n handler for a task. ^ , 
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o 
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CREATE SEGMENT 


Allocates dynamically an area of memory of a specified length In 1 6-Byte 
paragraph units up to a maximum of 64K Bytes (for example, for use as a 
buffer). Returns a location token for the segment allocated. 


G 
M 




HA-alliv^fltAe fliA mamnnt QoniTMint irvli/^teri hu thA nammptpr tnkRn 

Gll.l\A«ClliBO U IV illwll.lWIT II.HiillwCKK7U VJj ll ^Oll C11 ■ IdCI lli^rvd 


E 
N 
T 


ENABLE DELETION 


Allows the system data type value indicated by the location token to be 

H plpt pH 




DISABLE DELETION 


Prevents the system data type value indicated by th^ location token from 
being aeieted. 




URcATc MAILBUX 


Creates a mailbox with the specified task queueing discipline. Returns a 
location token. 


M 
A 


DELETE MAILBOX 


Deletes a mailbox, and returns its memory. If tasks are waiting for the 
mailbox, they are awakened (their state is made ready) with an appropriate 
exception condition. If messages are waiting for tasks, they are discarded. 


-1 m o X 


SEND MESSAGE 


Sends a message segment to a mailbox. 


RECEIVE MESSAGE 


A task is ready to receive a message at a mailbox. The task is placed on the 
mailbox task queue. The task may optionally wait for a response in- 

Hpfinitfilv/ nr 3 numhpr nf timp intprvalQ /npnpmlli/ 10 mQ Innn^ nr nnf sit fill 
uc;iMiiic.iy, \ji a iiuiiikjcr wi iinic ii iid vaio ^^diciaiiy lu iiio luiiu^, \ji i nj\ on cut. 

When complete, the primitive returns to tfie task the location token of the 

message segment received. 




CREATE REGION 


Creates a region data type value specifying a queueing discipline. Returns 
a token for the region. 


R 

E 


DELETE REGION 


Deletes a region if and only if the region is not in use. 


G 
1 

O 
N 


ACCEPT CONTROL 


Gains control of a region if it is immediately available, but does not wait if it is 
not available. 


RECEIVE CONTROL 


Is the same primitive ais accept control but the task that performs it may 

elect to wait. 




SEND CONTROL 


Relinquishes a region. 



Programmable Timers 

The 80186 provides three internal 16-bit programma- 
ble timers. Two of these are highly flexible and are 
connected to four external pins (two per timer). They 
can be used to count external events, time external 
events, generate nonrepetltlve waveforms, etc. The 
third timer is not connected to any external pins, and is 
useful for real-time coding and time delay applica- 
tions. In addition, this third timer can be used as a 



prescaler to the other two, or as a DMA request 
source. The factory default configuration for timer is 
baud rate generator. 

The 80130 provides three more programmable 
timers. One is a factory default baud rate generator 
and outputs an 8254 compatible square wave to the 
RS232 Channel B. The other two timers are assigned 
to the use of the OSF and should not tm altered by the 
user. 
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Tlie system s^t«i«H« GcmflpffiBS eadi timer indepen^ 
denUy to selaet-ttie dasirad kincSon. Examples of 
available fwK^Oom are shown in Table 3. The contents 
of each coutitsrnHqr Ise read at any time during sys- 
tem operation. 



Interrupt GapitfiMMiF -ir ^ ; -f 

The iSBC 1 86/51 S has two programmable interrupt 
controllers (PICs): one in the 80186 component and 
one in the 80130 component. In the iRMX mode, the 
801 86 interrupt controller acts as a slave to the 801 30. 
The 801 86 Interrupt controller in this mode uses all of 
its external interrupt pins. It therefore services only 
internally generated interrupts (i.e., three timers, two 
DMA channels). The 80130 interrupt controller 
operates in the master mode and has eight prioritized 
inputs that can be programmed either edge or level 
sensitive.- , 

The iSBC 186/51S board provides 9 vectored interrupt 
levels. The highest level is the NN^I (Non-Maskable 
Interrupt) line which iadirecUy tied to the 801 86 CPU. 



Table 3. 80186 Programmable Timer Functions 



Function 


Operation 


Interrupt on 
terminal count 


When femff^mjnt Is reached, an interrupt request is generated. Thi^ tun^HSA M ex- 
tremely useful for generation of real-time clocks. 


Pre®i«TOipble 
onSffM- 


Output goes low upon receipt of an external trigger edge or software command and 
returns high when terminal count is reached. This function is retriggerable. 


Rate generator 


Divide by N counter The output will go low for one input clock cycle, and the period 
from one low going pulse to the next is N times the input clock period. 


Square-wave rate 
generator 


Output will remain high until 1/2 the count has been completed, and go low for the 

otiwr tiaff of tmw^ 


Software 

triggered strobe 


Output remains high until software loads courrt (IiQl |<i periods after count is loaded, 
output goes low for one input dock period. 


Hardware 
triggered strobe 


Output goes low for one clock period N counts after rising edge counter trigger input. 

The counter is retriggerable. 


Event counter 


On a jumper selectable basis, the clock input becomes an input from the external 
system. CPU may read the number of events occurring after the counter "window" 
has been enabled or an interrupt may be generated after N events occur in the 

system. 



This interrupt is typically used for signaling «rta- 
strophic events (e.g., power failure). The Programma- 
ble Interrupt Controllers (PIC) provide control and 
vectoring for the next eight interrupt levels. As shown 
in Table 4, a selection of four priority processing 
modes is available for use in designing request pro- 
cessing configurations to match system requirements 
for efficient interrupt servicing with minimal latencies. 
Operating modes and priority assignments may be 
reconfigured dynamically via software at any time 
during system operation. The PIC accepts interrupt 
requests from all on-board I/O resources and from the 
IVIULTIBUS system bus. The PIC then resolves re- 
quests according to the selected mode and, if appro- 
priate, issues an interrupt to the CPU. 



ISBC 186/518 Interrupt Service requests may originate 
from 25 sources. Table 5 contains a list of devices and 
functions supported by interrupts. All interrupts are 
jumper configurable with either suitcase or wire wrap to 
the desired interruplfl^piiMNmiel: 
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Tabte 4. ISBC* 188/51 Programmable IntenuiM ModM 



Mode 


Operation 


Fully nested 


Interrupt request line priorities fixed at as highest, 7 as lowest. 


Special fully 
nested 


Allows multiple interrupts from slave PICs to the master PIC. Used in the case of 
cascading where the priority has to t>e conserved within each slave. 


Speicif ic priority 


System software assigns lowest priority level. Priority of all other levels based in 
sequence numerically on this assignment. 


Polled 


System software examines priority-encoded system Interrupt status via Interrupt 
status register. 



Table 5. Interrupt Request Sources 



Device 


Function 


Number of 
Intanrupto 


N^ULTIBUS" interface 


Requests from MULTIBUS® resident peripherals or other CPU 


2 


8274 


Transmit buffer empty, receive buffer full and channel errors 


8 


Internal 80186 
PIC 


Timer 0, 1 , 2 outputs (function determined by timer mode) and 2 
DMA channel Interrupts 


5 


82586 LCC 


Communications processor needs attention 


1 


Flag byte interrupt 


Flag byte interrupt set by MULTIBUS master 


1 


Systick 


80130, RMX system timer 


1 


Edge to level trigger 


Converts EDGE imerrupts to level interrupts 


1 


iSBX'" connectors 
MULTIMODULE™ 


Function determinod by iS6X*' 


4 

(2 per iSffi(™ 
connectoi^ 


Bus fail safe timer 


Indicates addressed MULTIBUS® resident device has not 
responded to command within 6 msec 


1 


OR-gate matrix 


Outputs of OR-gates on-board for multiple interrupts 


1 



I/O FUNCTIONALITY 

Local Communications Controller 

The 82586 is a local communications controller de- 
signed to relieve the lAPX 1 86 of many of the tasks 
associated with controlling a local network. The 82586 
provides most of the functions normally associated 
with the data link and physical link layers of a local 
networi^ architecture. In particular, It performs framing 



(frame boundary delineation, addressing, and bit error 
detection), link management, and data modulation. It 
also supports a network management interface. 

The iAPX 186 and the 82586 communicate entirely 
through a shared memory space. To the user, the 
82586 appears as two independent but communicat- 
ing units: the Command Unit (CU) and the Receive 
Unit (RU). The CU executes the commands given by 
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inter 



the iAPX 1 86 to the 82586. The RU handles all activi- 
ties related to packet reception, address recognition, 
CRC checking, etc. The two are controlled and moni- 
tored by the CPU via a shared memory structure 
called the System Control Block (SCB). Commands 
for the CU and RU are placed Into the SCB by the host 
processor. Status infonnatlon is placed into the SCB 
bytheCUandRU(viatheCU).The Channel Attention 
and Internist InesareiBBdby^wCM and ti»82^ta 
get the other to^ (Qofe Into tte SCB. Sw -PiOW*»< 4 



The 82586 features a high level diagnostic or mainte- 
nance capability It automatically gathers statistics on 
CRC errors, frame alignment errors, overrun errors, 
and frames lost due to lack of reception resources. In 
addition, the user can output the status of all internal 
registers to facilitate system design. 



Upon initialization, the 82586 ot>tains the adldi^ of 
Its System Control Block through the InWaHzaHon 
Fioot wMeh begins at location 0FFFFF6H. See F^ure 
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4. The SCB contains control commands, status regis- 
ter, pointers to ttre Command Bloci< List (CBL) and 
Receive Frame Area (RFA), and tallies for CRC, 
Alignment, DMA Overrun and No Resource errors. 
Through the SOB, the 82586 is able to provide status 
and error counts for the iAPX 86, execute "programs" 
contained in the CBL and receive incoming frames in 
the Receive Frame Area (RFA). 

Serial I/O 

Two programmable communications interfaces us- 
ing the Intel 8274 Multi-Protocol Serial Controller 
(MPSC) are contained on the iSBC 1 86/51 S. Two 
independent software selectable BAUD rate 
generators provide the channels with all the com- 
mon communications frequencies. The mode of 
operation (for example, Asynchronous, Byte Synch- 
Wious or Bisynchronous protoooJs), data format. 



control character format, parity, and baud rate are 
all under program control. The 8274 provides full 
duplex, double buffered transmit and receive 
capability. Parity, overrun, and framing error detec- 
tion are all incorporated In the MSPC. The iSBC 
1 86/51 S supports operation In the polled, interrupt 
and DMA driven interfaces through jumper options. 
The board comes factory defaulted with channel A in 
RS-422A/RS-449, channel B in RS-232C. Channel A 
be c8MifiiBi*ed to support RS-232C. 



iSBX " MULTIMODULE " 
On-Board Expansion 

Two 8/16-bit iSBX MULTIMODULE connectors are 
provided on the ISBC 186/51S microcomputer. Through 
these connectors, addtttonal on-board I/O functions 
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mi^ be addML ISiM imTlMODULE boards op- 
tinni^ aifip^MliixSiom piovided by VLSI peripheral 
oainpbnentssudi as additional parallel and serial t/O, 
analog VO, small mass storage device controlfers 

(e.g., cassettes and floppy disl<s), and other custom 
interfaces to meet specific needs. By mounting di- 
rectly on tfie single board computer, less interface 
logic, less power, simpler packaging, higfier perfor- 
mance, and lower cost results wfien compared to 
other alternatives such as MULTIBUS form factor 
compatible boards. The iSBX connectors on the iSBC 
1 86/51 S boards provide all signals necessary to inter- 
face to the local on-board bus, including 16 data lines 
for maximum data transfer rates. iSBC MULTIMODULE 
boards designed with 8-bil data paths and using the 
frbit iSBX connector are also supported on the ISBC 
186/51S microcomputers. A broad range of ISBX 
MULTIMODULE q^ens are available in this family 
from Intel. Custom ^SX modules may also be designed 
for use on the iSBC 1 86/51 S boards. An iSBX bus inter- 
face specification and ISBX connectors are available 
from Intel. 



MEMORY FUNCTIONALITY 



RAM Capabilities 

The ISBC 186/51S COMMputer board contains 128K 
Bytes of dual-port dynamic RAM. The on-board RAM 
may be expanded to 256K Bytes with the iSBC 304 
MULTIMODULE board mounted onto the iSBC 
186/51 S board The dual-port controller allows access 
to the on-boa^'W\K»pieludlng RAM MULTIMODULE 
options) from tKe ISBO 1 86/51 S board and 
from am/ oMr MtJUflBI^ master via the system 
bus: ^gin«l«soF«iviotird nAM may be configured 
as a fmm immm, protected from MULTIBUS 
system encess. The amount of memory allocated as 
a private resource may be configured in increments 
of 25% of the total on-board memory ranging from 
0% to 100% (optional RAM MULTIMODULE board 
doubles the increment size). These features allow 
the multiprocessor systems to establish local 
memory for each processor and shared system 
memory configurations where the total system 
memory size (including local on-board memory) can 
exceed one megabyte without addressing conflicts. 

Universal Memory Sites for Local Memory 

Six 28-pin sockets are provided for the use of Intel's 
27^.2764.27128, 27256 EPROMs and their respec- 
tive ROMs. When using the 27256s, the on-board 



EPROM capacity is 192K Bytes. Otm'JBBU^^tm- 
daid pinout devices are also su|ii|^cMteet meMng 
byle-wi#B ^ic mMs and iRAMs 



MULTIBUS® SYSTEM BUS AND 
MULTIMASTER CAPABILITIES 

Overview 

The MULTIBUS system bus is Intel's industry stan- 
dard microcomputer bus structure. 6 arid 1 S-bit 
single board computers are supported ORiiii>MWTI- 
BUS structure with 24 address and 16 d^ Ibtes. In its 
simplest application, the MULTIBUS system bus al- 
lows expansion of functions already contained on a 
single board computer (e.g., memory and digital I/O). 
However, the MULTIBUS structure also allows very 
powerful distributed processing configurations with 
multiple processors and intelligent slave 10, and pe- 
hpheral boards capable of solving the most demand- 
ing microcomputer applications. The MULTIBUS 
system bus is supported with a broad array of board 
level products, LSI interface components, detailed 
put>lished specifications and application notes. 

Expansion Capabilities 

Memory and I/O capacity may be expanded and addi- 
tional functions added using Intel MULTIBUS com- 
patible expansion boards. Memory may be expanded 
by adding user specified combinations of RAM 
boards, EPROM boards, or combination boards. In- 
put/output capacity may be added with digital I/O and 
analog I/O expansion boards. Mass storage capability 
may be achieved by adding single or double density 
diskette controllers, or hard disk eomoll»m. Medtilar 
expandable backplanes and oadalgeB are«MBH«ble 

tKfSUMiiitmMiisNi-siaieMS'. - ' 

' . .1.-- ■ , . - . 

Multimaster Capabilities 

For those applications requiring additional processing 
capacity and the benefits of multiprocessing (i.e., 
several CPU's and/or controllers logically sharing sys- 
tem tasks through communication of the system bus), 
the ISBC 186/518 boards provide full MULTIBUS ar- 
bitration control logic. This control logic allows up to 
three iSBC 186/51S boards or other bus masters, in- 
cluding ISBC 80 family MULTIBUS compatible 8-bit 
single board computers to share the system bus using 
a sehal (daisy chain) pnority scheme. This allows up to 
16 masters to share the MULTIBUS system bus with 
an external parallel priority decoder In addition to the 
multiprocessing configurations made possible with 
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imttimaster capability, it also provides a very efficient 
iiiBchanIsm for all forms of DMA (Dired Memory Ac- 
eess) transfers. 



M^ELLANEOUS FUNCTIONALITY 

Power-Fail Control and Auxiliary Power 

An active-low TTL compatible memory protect signal 
is brought out on the auxiliary connector which, when 
asserted, disables read/write access to RAM memory 
on the board. This input is provided for the protection 
of RAM contents during system power-down se- 
quences. An auxiliary power bus is also provided to 
allow separate power to RAM for systems requiring 
battery back-up of read/write memory. Selection of 
this auxiliary RAM power bus Is made via jumpers on 
tfie board. 

System Development Capabilities 

The development cycle of iSBC 1 86/51 S products can be 
significantly reduced and simplified by using either the 
System 86/3XX or the Intellec Series Microcomputer 
Development Systems. The Assembler, Locating Linker, 
Library Manager, Text Editor and System Monitor are all 
supported by the ISIS-II disk-based operating system. To 
facilitate conversion of the 808QA/8085A assembly 
language programs to run on the iSBC 186/51S boards, 
O0ilV-86 is available under the IStS-ll operating ^em. 

In-dreuR Emulator 

The Integrated Irt^rumentation InOircuit Emulator 
(I ICE) provides the necessary link between the soft- 
ware development environment provided by the Intel- 
lec system and the "target" ISBC 186/51S execution 
^tem. In addition to providing the mechanism for 
loading executable code and data into the ISBC 



186/51S boards, the KICE-186 provides a sophisti- 
cated command set to assist In debugging software 
and final integration of the user hardware and 
software. 

PL/M-86 and C-86 

Intel has two systems Implementation languages, 
PUM-86 and C-86. Both are standard In the System 
86/3XX and are also available as Intellec Microcom- 
puter Development System options. PL/M-86 pro- 
vides the capability to program in algorithmic 
language and eliminates the need to manage register 
usage or allocate memory while still allowing explicit 
control of the system's resources when needed. C-86 
is especially appropriate in applications requiring por- 
tability and code density FORTRAN 86 and PASCAL 
86 are also available on Intellec or 86/3XX systems. 

Run-Time Support 

Intel also offers two run-time support packages: iRMX 
88 Realtime Multitasking Executive and the iRMX 86 
Operating System. The IRMX 88 executive is a 
simple, highly configurable and efficient foundation for 
small, high performance applications. Its multitasking 
structure establishes a solid foundation for modular 
system design and provides task scheduling and 
management, intertask communication and 
synchronization, and interrupt servicing for a variety of 
peripheral devices. Other configurable options in- 
clude terminal handlers, disk file system, debuggers 
and other utilities. The iRMX 86 Operating System Is a 
highly functional opera^ting system with a very rich set 
of features and opttons based on an object-oriented 
architecture. In addition to being modular and con- 
figurable, functions beyond the nucleus include a so- 
phisticated file management and I/O system, and a 
powerful human interface. Both packages are easily 
customized and extended by the user to match unique 
requirements. 
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SPECIFICATIONS 



Word Site 

Instruction— 8, 16, 24, or 32^6fts 
Data— 8, 16 bits 



&00 MHz ± 0.1% 



Cycle Time 

Basic Instruction Cycle 

6 MHz— 1000ns 

333ns (assumes instruction in the queue) 

Note; Basic instruction cycle is defined as tine fastest 
instruction time (i.e., two clod( eydes.) 

Memory Response TIrtie 

Ha* Mif> 
AccMs Tttne Cycle Time 

RAIVI — 750ns 
Univ^sal Memory Sites 200ns 500ns 
Jumper Selectable 300ns 625ns 



Memory Capacity/Addressing 

Six Universal Memory Sites support JEDEC 24/28 pin 
EPROM, PROM, iRAM and static RAM. 



I/O Capacity 

Serial — two programmable channels i&i^ one 8274 
..tlSBX'" Multimodule™— two 8/16.bit iSBX'" connec- 
Jbrs allow use of up to 2 single^'Mide modules or 1 
sii3s;i^)te')|*te miie «ad 1 toible-wide iSBX module. 

Serial Communications Characteristics 

Synchronous — 5-8 bit characters; internal or ex- 
ternal character synchronization; 
automatic sync insertion 
-5-8 bit characters; breal< charac- 
ter generation; 1, 1/2, or 2 stop bits; 
laMiMFt bit detection 



Example for EPROM: 
Device Total Capacity 

2732 

2764 
27128 
27256 19^%tes 



Address Range 

COQOO-PFFFFh 



On-Board RAM 

Board Total Capacity Address Range 

iS^tl^t 128KBy^ i*iWpH 

tmjmmm:^' mm 

Board Total Capacity Address Range 

tSBC 304 256K Bytes 0-3FFFFh 



A^nchronous 



Baud Rates 



Frequency 
(KHz) (S/W 
Selee^e) 


Baud Rate (Hz) 


Synchronous 


Asynchronous 




H-1 


^16 


^64 


153.6 




9600 


2400 


W.8 




4800 


1200 


38.4 


38,400 


2400 


600 


19.2 


19.200 




WO 


9.6 


9,600 


600 


150 


4.8 


4,800 


300 


75 


2.4 


2,400 


150 




1.76 


1,760 


110 


2400 



NOTE: 

Frequency selected t)y I/O 1Mt6 Of jif^reiprjate 16-liiit fre- 
quency factor to baud rate register (80186 tlitiei' & 80130 
baud timer). 



Timers 

input Frequencies 

fMsram 1.5 MHz ± 0,1% (.^iSec period nominal) 
Iwent 1.5 MHz mmt^ 
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80186 Output Frequendes/Timli^ Intervals 



Function 


Single 
Timer/Counter 


Dual (Cascaded) 
Timer/Counter 


Min 


Max 


Min 


Max 


Real-time 
Interrupt 


e67ns 


43.68016 


667ns 


47.72 minute 


Programmable 
one-siwl 


1000ns 


43.69ms 


1000ns 


47.72 minutes 


Rate generator 


22.889 Hz 


1.5 MHz 


.0003492 Hz 


1.5 MHz 


Square-wave 
rate generator 


22.889 Hz 


1.5 MHz 


.0003492 Hz 


1.5 MHz 


Software 
triggered strobe 


1000ns 


43.e9ins 


tOOOns 


47.1^ minut«} 


Event counter 




1.5 MHz 







Interfaces 

Ethernet— IEEE 802.3 compatible 
MULTIBUS®— IEEE 796 compatible 
MULTIBUS®— Master D16 M24 116 VO EL 



Compliance 

iSBX'" Bus— IEEE P959 compatible 
Serial I/O— RS-232C compatible, 

configurable as a data set or 
data terminal. RS-422A/RS-449 



Connectors 



Intertece 


Double-Sided 
Pins 


Centers 
(In.) 


Mating 
Connectors 


Ethernet 


10 


0.1 


AMP87531-5 


MULTIBUS* SYSTEM 


86 (P1) 


0.156 


Viking 

3KH43/9AMK12 
Wire Wrap 


60 (P2) 


0.1 


Viking 

3KH30/9JNK 


iSBX'" Bus 
8-Bif Data 

16-Bit Data 


36 


0.1 


iSBX™ 960-5 


44 


0.1 


iSBX™ 960-5 


Serial I/O 


26 


0.1 


3M 3452-0001 
Flat or 

AMP88106-1 Flat 



2H 



inter 



Physical Characteristics 

Width— 12.00 in. (30.48 cm) 
Height— 6.75 in. (17.15 cm) 
Depth— 0.70 in. (1.78 cm) 
Vyteight — 1 8.7 ounces 



Environmental Characteristics 

Brature— 0°C to 55°C 
^—10% to 90% (without 
condensation) 



Operating Ten 
Relative Riwiii 



Electrical Characteristics 
DC Power Supply Requirements 


-4.. 

n, 




ar - 

• 




Configuration 


Maximum Current 
(All Voltages ± 5%) 


+5 


+ 12 


-12 


SBC 186/51S as shipped: 
Board Total 

With separate battery back-up 
Battery back-up 


7.45A 
LISA 


40mA 
40mA 


40mA 
40mA 


With SBC-304 Memory Modula . 

Installed; 
Board Total 

With separate battery back-up 
Battery back-up 


7.55A 
6.30A 


40mA 
40mA 




40mA 
40mA 



NOTES: 

1 . Add 1 50 mA to 5 V current for each device Installed In the 6 available Universal Meinory Sites. 

2. Add 500 mA to 12V current if Ettiemet transceiver is connected. 

3. Add additional currents ter any SBX modules installed. 



Reference Manual 

122136-001— iSBC 186/51 Hardware Reference 
tWIanual (NOT SUPPLIED) 



Manuals may be ordered from any Intel sales repre- 
sentative, distritHitor office or from Intel Literature De- 
partment, 3065 Bowers Avenue, Santa Clara, 



ORDERING INFORMATION 

Part Number Description 

SBC 186I51S Communicating Computer 

t 

■r " ' 



25 



ntel' 



iNA 960 TRANSPORT SOFTWARE 

MEMBER OF THE OpenNET™ PRODUCT FAMILY 



ISO Transport (8073) Class 4 services 
— Guaranteed message Integrity 
— Data rate matching (flow control) 
— IMultiple connection capability 
— Variable length messages 
—Expedited delivery 
— Negotiation of virtual circuit 
characteristics during opens 

Additional functionality 
— Connectionless transport 

(Datagram) 
— External Data Link 

IEEE 802.3 Data Link protocol 
(CSMA/CD) supported 

Comprehensive Network Management 
services 



— Collection of network usage 
statistics 

— Setting and inspecting of transport 

and data link parameters 
—Fault isolation and detection 
— Boot Server 

Compatible with multiple system 
environments 

— Runs as an IRMX " 86 job 
— Supports host operating system 
independent designs based on 8086, 
8088 or 80168 and 82586 components 

Runs on iSBO*188S1 COMM|iiitwW 
Board 

Preconf Igured version nins on SXM 552 
Transport Engine 



INA 960 is a general purpose local area network software package Implementing the class 4 services of the 
ISO transport specification and network management functions In system designs based on the 8066, 8088 

and 80186 microprocessors and the 82586 communications co-processor. iNA 960 also supports Intel's board 
level LAN products, the iSBC* 552, iSXMTM 552, and the iSBC- 186/51. Combined with these board products 
INA 960 provides a cost effective, high performance industry standard transport capability supporting the 
OpenNET higtier layer software or other user application. a 



INA 960 is a ready-to-use software building block for OEM suppliers of networked systems for both technical 
and commercial applications. Examples for such applications include networked design stations, manufac- 
turing process control, communicating word processors, and financial services workstations. Using the INA 
960 software the OEM can minimize devetopment cost and time white achieving compatibility with a growing 
number of equipment suppliers adapting ttie IEEE and ISO standards. 




Figure 1. 

Intel Corporation Assumes No Responsibility for the Use ol Any Circuitry Other Than Circuitry Embodied in an Intel Product. No Other Circuit 
Patent Licenses are unpiied Information Contained Herein Supercedes Previouily Published SpecifiGaHans On These Oavicae From hital. 

t INTEL CORPORATION 1984 
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FUNCTIONAL OVERVIEW 

The iNA 960 design is a standard implementation of 
the Class 4 transport protocol defined by the ISO OSI 
model The Transport Layer provides a reliable full- 
duplex message delivery service on top of the "best 
effort IEEE 802.3 standard packet delivery service 
implemented by the 82586 (or equivalent) pilySiefl 
and data link functions. 

Consisting of linkable modules, the software can be 
configured to implement a range of capabilities and 
interface protocols. In addition to reliable process-to- 
process message delivery, the capabilities Include a 
datagram service, a boot server, a direct user access 
to the Data Link Layer, and a comprehensive network 
management facility. 

iNA 960 can be configured to run under iRMX 86 
along with the user software, or to run on top of a 



dedicated 8086, 8088 or 80186 processor coupled 
with an 82586 to provide a communications front end 
processor. 

The software also includes a Network Management 
service. This facility enables the user to monitor and 
adjust the network's operation in order to opHMz^ite 
performance. 

The current release of iNA 960 ineiiKles a "null" Net- 
work Layer supporting the Da^iMk-wnA Transport 
Layers without prowditli MMMlMiifk Mttug ser- 
vice. This capability be irr^temeBtecf in terter 
flames of iNA 960. 

For a concepitual bkKk jKepram of iNA 960. refer to 
Figured. 
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Figure 2. iNA 960 Conceptual Block Diagram 
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TRANSPORT LAYER 

The Transport Layer provides message delivery 
services between client processes running on com- 
puters (network "hosts" or "nodes") anywhere in the 
n^^ork. 

Client processes are identified by a combination of a 
network address defining tfie node and a transport 
service access point defining the interface point 
through which the client accesses the transport 
services The combined parameters, called the 
transport address, are supplied by the user for both 
the local and the Fernote client processes to iDe 
connected. 

The INA 960 transport layer implements two kinds of 
message delivery services: virtual circuit and 
datagram. The virtual circuit provides a reliable point- 
to-point message delivery service ensuring maxi- 
mum data integrity, and it is fully compatible with the 
ISO 8073 Class 4 protocol. The datagram service 
provides a best effort message delivery between 
client processes requiring less overhead and 
therefore allowing higher throughput than virtual 
circuits. 

Both the datagram and the virtual circuit services are 
optional and can be included wtren configuring 
iNA 960. 

Virtual Circuit Services 

— Reliable Delivery: Data is delivered to the destina- 
tion in the exact order it was sent by the source, 
with no errors, duplications or losses, regardless of 
the quality of service available from the underlying 
network service. 

^Data Rate Matching (flow control): The Transport 
Layer attempts to maximize throughput while 
conserving communication subsystem resources 
by controlling the rate at which messages are sent. 
That rate is based on the availablity of receive but- 
ters at the destination and its oWn resources. 

— Multiple Connection Capability (Process Multiplex- 
ing): Several processes can be simultaneously 
using the Transport Layer with no risk that prog- 
ress or lack of progress by one process will inter- 
fere with others. 

— Variable Length lylessages: The client software 
can submit arbitrarily short or long messages for 
transmittal without regard for the minimum or max- 
imum network service data unit (NSDU) lengths 
supported by the underlying network services. 



— Expedited Delivery (optional). With this service the 
client can transmit up to 16 bytes of urgent data 
bypassing the normal flow control. The expedited 
data is guaranteed to arrive before any normal data 
submitted afterward. 

Connectionless Transport 
(Datagram) Service 

The datagram service transfers data between client 
processes without establishing a virtual circuit. The 
service is a "best effort" capability and data may be 
lost or misordered. Data can be transferred at one 
time to a single destination or to several destinations 
(multicast). 

NETWORK MANAGEMENT FACILITY (NMF) 

The network management facility provides the users 
of the network with planning, operation, maintenance 
and initialization services described below. 

— Planning: This service captures network usage 
statistics on the various layers to help plan network 
expansion. Statistics are maintained by the layers 
themselves and are made availatile to users via an 
interface with the NMF. 

^Operation: This service allows the user to monitor 
network functions and to inspect and adjust net- 
work parameters. The goal is to provide the tools 
for performance optimization on the network. 

—Maintenance: This service deals with detecting 
isolating and correcting network faults, it also pro- 
vides the capability to determine the presence of 
hosts and the viability of their connection to the 
network. 

— Initialization: NMF provides initializatun and remote 
loading facilities. 



Network management provides distributed manage- 
ment of the network; the user can request any of the 
services to be performed on a remote as well as a 
local node The NMF interfaces to every other net- 
work layer both to utilize their sen/ices and to access 
their internal cteta bases. 



In support of the above services, the NMF capabilities 
include layer management, echo testing, limited 
debugging facilities, and the ability to down line load 
and dump a remote system. 
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Layer management deals with manipulating the in- 
ternal database of a layer. The elements of these data 
bases are termed objects. Some examples tor objecte 
are the number of collisions, rett^nsmissiw ttm»^ 
limit, the number of packer smit, mt the list of nodes 
to boot. HMF can examine and objects in a 
layer's data base. 

An echo facility is provided. Using this facility the host 
can determine if a node is present on the networl< or 
not, test the communication path to that node and 
determine whether the remote node is functional. 

NMF enables the user to read or write memory in any 
host present on the network. This feature is provid- 
ed as an aid to debugging. 

NMF can down line load any system present on the 
network. A simple Data Link protocol is used to en- 
sure reliability. This facility can be used to load 
databases, to boot systems without local mass 
storage or to boot a set of nodes remotely, thus en- 
suring that they have the same version of software, 
etc. 

Dumping is an ^er^lon eiiuivaleft to memory read 
from the user's Stattdpoing howe^r, dumping uses 
the Data Link feK;iiities while mefflbry read uses the 
transport facilities. 



EXTERNAL DATA LINK (EDL) 

The External Data Link option allows the user to ac- 
cess the functionalities of the Data Link Layer directly 
instead of having to go through the network and 
transport layers. This flexibility is useful when the 
user needs custom higher layer software, or does not 
need the Network Layer and Transport Layer 
services (e.g.. when sending "best effort" messages, 
or running customer diagnostics). 

Through the EDL the capabilities supporting the 
lower layers in iNA 960 are masie diret^ available to 
the user. EDL enables the user 1& ebti^tett &fsi 
delete data link connections, tntnsmit paitds^s to indi- 
vidual and multiple receivers, and emSffutim the dita 
link software to meet the requirements of the given 
network environment. 



USER ENVIRONMENT 

iNA 960 is designed to run on hardware based on the 
8086. 8088 or 801 86 microprocessors and the 82586 
LAN Coprocessor. The software can be configured to 
run under iRMX 86 or on a dedicated 8086, 8088 or 
80186 processor separately from the host. The fol- 
lowing section describes these two operating 
environments. 



Ifmyiil fmitrirMtmiMit 
MmW*^ 'UIVHIMUIVUVn 

In this configuration, bott> the user program and iNA 
960 are running under tRMX 86. The communica- 
tions software is implemented sts an iRM^ 86 job 
requiring the nucleus only for most operations. The 
only exception is the boot server option which also 
needs the Basic I/O System. iNA 960 will run in any 
iRMX environment including configurations based on 
the 80130. See Figure 3 and 4 for an Illustration of iNA 
960 running under IRMX 86. 



Operating System/Precessor 
tfiit^ndent lm^ilem«ntation 

In those systems where iRMX 86 is not the primary 
operating system, where off-loading the host of the 
communications tasks is necessary for performance 
reasons, or where an existing communicaliorts front- 
end processor configuration is Mng upgraded, the 
user may wish to dedicate a processor for communi- 
cations purposes. iNA 960 can be configured to sup- 
port such implementations by providing network 
services on an 8086, 8088 or 80186 processor. Fig- 
ure 5 depicts the conceptual block diagram of this 
configuration. The SBC & SXM 552 are 
MULTttUS^ kn^ementatjans sf this architecture. 



This approach provides the component and system 
designer with an ISO standard communications soft- 
ware building block that can be adapted to his sys- 
tem's needs with a minimum interfacing effort. For 
added flexibility, iNA 960 provides the u^ with the 
altematii«e ^ mitig the lijdueM interface module or 
writing MM ft^iMet # tsiecessary. 
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USER INTERFACE 

iNA 960 Is designed to run both under iRMX 86 and 
on a dedicated communications front end processor 
separately from the host. In both environments, the 
interface Is based on exchanging memory segments 
called request blocks between INA 960 and the 
client. The format and contents of the request blocks 
remain the same In both configurations; only the re- 
quest bloek delivery mechanism changes. See Fig- 
ure 6 for a simplified interface diagram. 

Request blocks are memory segments containing the 
data to be passed from the user to INA 960 
(commands), or from INA 960 to the user 
(responses). The INA 960 request blocks consist of 
fixed format fields identical across all user com- 
mands and argument fields unique to the individual 
commands. Refer to Figure 7 for the standai^d re- 
quest block format. 



Issuing an iNA 960 command consists of filling in the 
request block fields and transferring ftie block to INA 
960 for execution. After processing the command, 
INA 960 returns ttie request block with one of the 
pre-defined response codes placed in the response 
code field of the request block. The response code 
indicates whether the command was executed suc- 
cessfully or whether an error occurred. By examining 
the response code, the user can take appropriate 
a^on tor ttiat Command. 

For iRMX users, iNA 960 also provides a procedural 
interface option to simplify writing the application 
software interface, in this case, the allocation and 
formatting of request blocks are replaced by a proce- 
dure call with parameters that specify the user's com- 
mand options. The procedure execution will create a 
request block and fill in the appropriate fields from ttie 
user's parameter list. 




Figure 6. 



For component users the request block delivery 
mechanism is the means by which the host processor 
and the communications processor running INA 960 
software exchange the request blocks. INA 960 pro- 
vides three such mechanisms: the MIP (Multibus 
Inter-process Protocol), the BCB (Base Control Block) 
and a user-defined mechanism. The MIP interface is 
included for use in systems already supporting this 
protocol; the BCB is a simple interface for single host 
environments, and the user-defined interface accom- 
modates unique application requirements. 
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Transport Layer User Interface 



The following table summarizes the user commands and the corresponding transport layer responses. 



Command 


Function 


1. OPEN 


Allocates memory for the connection data base of a virtual CirflUit (or 
connection) to be established. The conngstlon datgtiase contains 
data concerning the connection 


2: SBIO CONNBCT 
REQUEST 


Requests connection to a fully specified remote transport address 
using specified ISO connection negotiation options. 


3. AWAIT CONNECT 
REQUEST TRAN 


Indicates that the transport client is wittinfl to consider incoming con- 
nection requests based on pre-establWiedteceptance criteria. 


4. AWAIT CONNECT 

REQUEST USER 


Indicates that the transport client is willing to consider incoming con- 
nection requests. If the request meets the address and negotiation 
option criteria, it is passed to the client for further consideration. 


5, ACCEPT CONfiCT • 
REQUEST 


Indicates that the connection requested by a remote transport ser- 
vice IS accepted by the client. 


6. SEND DATA or 
SEND EOM DATA 


With thfs command, the client requests the transmission of the data 
in the buffers using the normal delivery service of the specified 

connection. 

J" 

The SEND EOM DATA command SjgHat§-1f1««-tlT# ene Of the data 
marks the end of the transport service data unit. 


7. RECEIVE DATA 


Posts normal receive data buffers for a specific connection or for a 
buffer pool used by a class of connections. 


8. SEND EXPED;gS0^ T, 
DATA 


Transmits up to 1 6 bytes of data using the expedited delivery service. 
The expedited data is guaranteed to arrive at the destination before 
any normal data submitted afterward. 


9. RECEIVE EXPEDITED 
DATA 


Posts receive data buffers for expedited delivery for a specific con- 
nection or for a pool of buffers used by a class of connections. 


10. CLOSE 


Terminates an existing connection or rejects an incoming connection 

tec^mSLM^'^mmMm' 01^190^ 4S^''S0U^; Sip tO' be sent will not 
be s^fit. 


11. AWAIT CLOSE 


Requests notification of the client of the termination of a specified 

connection. 


12. SEND DATAGRAM 


Requests transmission of the data in the buffers using the transport 
datagram service. 


13. RECEIVE DATAGRAM 


Posts a receive buffer for a specific receiver or a class of receivers to 
receive data from a transport datagram. 
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Network Management Layer User Interface 



Command 


Function 


1 READ OBJECT 


Fleturns the value of the specified object to the client. 




Sets the value of an object as specified by the client. 


0. HcAU AND ULcAH 
OBJECT 


Returns the value of the specified object to the client then clears the 

object. 


4. ECHO 


This function is used to determine the presence of a node, to test the 
communication path to the node and to ascertain the vieibility and 

functionality of the remote host addressed. 


5. UP LINE DUMP 


Requests a remote node to dump a specified memory area. 


6. READ MEMORY 


Reads memory of the specified netv^ork node. 


7. SET MEMORY 


Sets memory of the specified network node. 


8. FORCE LOAD 


Causes a node to attempt a remote load from another node. 


External Data Link Interface 


Command 


Function 


1. CONNECT 


With this command the client establishes a data link connection. 


2. DISCONNECT 


Eliminates a previously established connection. 


3. TRANSMIT 


Transmits data contained in buffers specified by the client. 


4. POST RECEIVE PACKET 
DESCRIPTOR 


Allocates memory for maintaining records on receive data buffers. 
Also may be used to allocate memory for buffering receive data. 


5. POST RECEIVE BUFFER 


Allocates memory for buffering receive data. 


6. ADD MULTICAST 
ADDRESS 


Adds an address to the list of data link multicast addresses. 


7. REMOVE MULTICAST 
ADDRESS 


Removes an address from the list of data link multicast addresses. 


8. SET DATA LINK I D. 


Sets up a ufliout dai^ Miilc I.D. for the station. 
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CONFIGURING iNA 960 

In order to adapt iNA 960 to his specific application, 
the user must coniigure MS'Software to define the 
desired iunctiems, to setect the appropriate interface, 
to set the layer parameters and to set up for the 
required hardware configuration. 

There are a number of capability combinations the 
user may elect to implement in his application. At the 
transport layer level the options are: virtual circuit ser- 
vice with or without expedited delivery, or datagram 
service, or both. At the data link level, the user may 
include or exclude the External Data Link interface. 

The Network Management Facility is also optional. 



When it is configured in, the user may also include 
the boot server module. These capabilities can be 
made available simply by linking in the corresponding 
software modules. The interface options are also im- 
plemented in a modular fashion; the user links in the 
desired module to set up for the iRMX 86 or the 
operating system Independent ccnfigurations. 

Layer parameters and confiuration options are first 
edited into layer configuration files, then assembled 
and linked into iNA 960 Layer parameters adjust the 
network s operation to match the usage pattern and 
the available resources. For example, within the 
Transport Layer, the flow control parameters, the 
retransmission timer parameters, the transport data 
base parameters, etc. can be set via this process. 
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Figure 8. The (^nfiguratjon Process for iNA 960 
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f he user also sets up for the required hardware con- 
ftgurafion, such as port addresses and interrupt 
levels, during this process. For the flow diagram of 
configuring iNA 960. refer to Figure 8. 



SPECIFICATIONS 

Hifdware Supported: 

— iSBC 186/51 Communicating Computer 

—SBC 552 COMMengine 

— SXM 552 Transport Engine (runs with 
preconfigured transport software) 

—Custom designs based on 8086. 8088 and 80186 
microprocessors and the 82586 Local Communi- 
cations Controller 

Typical Throughput at transport: 

lEnvironments: 

186 51 and 50K to 200K bytes sec 

iRMX 86 

Dedicated 80186 1 0OK to 3Q0K bytes sec 

82586 COMMengine 

Memory Requirements: (in bytes) 



Available Literature/ 
Reference Materials: 

— iNA 960 Programmer's Reference Manual (11/83) 

— iSBC 186/51 DSta Sheet (Now) 

— iSBC 186/51 Hardware Reference Manual (11/83) 



ORDERING INFORMATION 

The following Is a list of ordering options for the iNA 960 

Transport Software. All options include a full year of up- 
date service that provides a periodic NEWSLETTER, 
Software Problem Report siarvice, and copies of 
system updates that occur during this period. All of the 
object code options listed are available on either ISIS or 
RMX connpatit>le double density dislwttes. 

As with all Intel software, purchase of any of these 
options requires the execution of a standard Intel 
Master Software License. The specific rights granted 
to users depend on the specific option and the 
License signed. 



Base System 



Normal Virtual 
Circuit Option 



Net Management Option 
External Data Linl( Option 
Boot Server Option 



12K plus con- 
figurable Buffer 
Memory 
18K plus con- 
figurable Buffer 
Memory 
2K 

3K plus Data Base 

Memory 

IK to 5K 

5K 

5K 



Expedited Delivery Option 
Datagram Option 
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Order Code 



iNA 960 YRO 

iNA 960 YST 
iNA 960 YBY 
iNA 960 YSU 
iNA 960 ESR 
iNA 960 LST 
iNA9!e» RF 



Description 



OEM object coii9 Hc^se requiring the payment of incorporation 
fees for each dSrivafive worl< based on iNA 960; ISIS and RIWX 

formatted diskettes 

Object code license to use the product at a second site or facility; 
ISIS and RMX formatted dlsicenes 

Object code buy-out licens»,fequirlng no further payment of incor- 
poration fees; ISIS and ^IIM8 formatted dislcettes 

Object code single use license diWir; 1)SIS afid 1^8 formatted 

diskettes ; ■ -. 

License for machine readable source code if iNA 960. RMX and 51V 
fbrmottad cgskettes , 

Source listing of iNA 960 provided on microfiche under a special 
source code license agreement 

(^ftfi^de for the payment of incorporation fees 
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iRMX™ N€TWORKING SOFTWAflE4RMX™-NET 

MEMBER OF THE OpenNETw PRODUCT FAMILY 



Transparent Network File Ae^^ra 

— Remote files can be worlced with as 
If they were local 

Connects IRMXtm, XENIX* aid DOS 
systems on the U\N** 

— Compatible with XENIX Netwoildng 
Software (XENIX* NET) and MS-NET/ 
IBM PC Networking program 

Runs under IRMX™ 86 Operating 
System 

Existing applications can be distributed 
without change 



Supports OpenNETTM— Ethernet 
hardware and software 

— iSXMTM 552 Transport Engine 
— iSBC® 552 COMMengine 

— ISBC« 186/51 COMMputerTii 

— iNA 960 Transport software 

Supports file server applications 

— Based on IRMXtm 86 BmieitO 
system 

Distributed name 



The Intel OpenNETTw iRMXTM Network File access software provides transparent file access between IRMX 
and XENIX* and IRMX and MS/DOS systenns across a LAN. Users can use local file systems commands to 
read, write, open, close, etc. files residing at remote iRMX, MS/ or PC/DOS and XENIX systems. IRMX NET 
implements the upper layer ISO OSI protocols used by the IBM PC Network Program and XENIX NET. 
Interoperation among these systems is supported by Intel's LAN product line including the iSXM 552 Transport 
engine, the iSBC® 552 COMMengine, the iSBC® 186/51 COMMputerTM and the iNA 960 Transport software. 
Networked IRMX systems serve in a wide range of applications including reei time ttansactions, automated 
testing, data collection, communications switching, etc. 



'XENIX is a trademark of Mterosoft Coip. 

"RMX to XENIX irrteroperatkm will be fully qualified only in R1.1 and up. 




Intel Corporation assumes no raapon^HI^ tor the use of any drcuiliy other than dnaiitiy embodnd in an Intel pnxkict No oltier diciiit patent 
licenses are implied. Information eontatned herein supeisades prmioiialy puHMwd specMcatioiB on these davioes from Intel. Faimaay IMS 

® Intel Corporation, 1 985 
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iRMXTM.NET FUNCT1@iilltc 
DESCRIPTION 

VMXf*'4l^ fWcnMes transparent remote file ac- 
cess capability ttwsi^^a censumer and a file 
servor fneitde. ffM ■wmumm IWiiR^pts file com- 
iramds Wm 9m Ibcstf Uoar'tsni 'WeBMifllR' ttiem 
across thei^Nto iem^amurm^ mOBmrnm the 

target file resides. The server receives. Interprets 
and executes the command acting as a user to its 
local file system. The user has the option of config- 
uring either or both in his target syston. 

RMX-NET also includes a name server which pro- 
vides name-to-address mapping. The iRMX-NET file 
consumer uses the name server to find the physical 
address of the referenced system. 



Ttae capabilities adiow iRimK sy^ams to interoperete 
oveir Ihe LAN wifli XENIX s^tems configured vnth 
XENIX-NET or DOS systems using MS-NET or IBM 
PC Network Program. This interoperation entails ac- 
cessing data and loading p^pps fwoimlbi ttp pt- 
work, sharing common sepMfsiuM coRnnirAcsdion 
between users. 

The network file service requires the support of an 
underlying ISO 8073 compatible transport service 
provided by the iNA 960 network software running 
on the iSBC 186/51 COMMputer or the iSXM 552/ 
iSBC 552 boards. In terms of the ISO OSI reference 
model iRMX-NET, in conjunction with the transport 
service and Ethernet/IEEE 802.3 hardware, provide 
complete seven layer functionality and serves as the 
fundamental building block for the development of a 
host of other services such as mail or yiitipl tm^ul 
(see Figure 1). 



APPLICATION 



PRESENTATION 



SESSION 



TRANSPORT 



DATA Um 



PHYSaqAL 



SOFTWARE 



BXM'" 
552 BOARD 



ISBC'"' 
186/51 
BOARD 



iRMX""-NET 
SOnWARE 



INA 960 
SOFTWARE 



FHpro 1. tSO OSI Referanea Modal RMX4IET 








WHICH 








PROTOCOL 


SUPPORTED 


CONSUMER 


SERVER 


USED 


IN 


iRMXTM 


iRMXTM 


EXT. 


R1.0 


IRMXTM 


XENIX 


EXT. 


R1.1 


XENIX 


IRMXTM 


EXT. 


R1.1 


XENIX 


XENIX 


EXT. 


R1.0 


XENIX 


DOS 


CORE 


R1.0 


DOS 


IRMXTM 


CORE 


R1.0 


DOS 


XENIX 


CORE 


R1.0 


DOS 


DOS 


CORE 


M/S NETWORK. 








IBM PC NETWORK 








SOFTWARE 



Figure 2. Protocols and Interoparalipn 



Table 1. Protocols 
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TRANSPARENT REMdH Wm 
ACCESS 

iRMX-NET provides transparent remote file access 
at the BIOS, ElOS and Human interface level. This 
means that all IRMX 86 applications written using 
BIOS, ElOS or HI commands can be used in a net- 
worked environment where the referenced files may 
reside at other nodes of the network. 

With Release 1 of RMX-NET the user (file consum- 
er) can transparently access files resident at remote 
systems configured with iRMX-NET or XENIX-NET 
(file servers). On the other hand, an RMX file server 
supports remote nodes configured with iRMX-NET, 
XENIX-NET, Microsoft Networks and IBM PC Net- 
work Software file consumers. For a table showing 
the combinations supported with the Initial Open- 
NET product line please refer to Figure 2. 

Transparent remote file access enables the user to 
manipulate and use remote flies as if they were lo- 
cal. This capability can be used to develop key net- 
work services, such as mail, print server or v(rtb»l 
terminal with minimum additional effort. 



PROTOCOLS 

File sharing among different operating systems 
across the network Is made possible through imple- 
menting a common set of file access (or file sharing) 
protocols under these operating systems. Network 
file sharing protocols are a set of rules governing the 
interaction between a file consumer and a file server 
on the same local area network. The file access pro- 
tocols used by the OpenNet product line wMraiointly 
developed Intel, Microsoft and IBM. 

Since the file systems of DOS, XENIX 286 and iRMX 
86 are not identical, two protocol sets have be^n 
devised to support transparency in the various serv- 



er-consumer combinations. The so-called "core pro- 
tocols" support transparent file access between two 
DOS nodes on the network. The "extended proto- 
cols" support transparent file access between iRMX 
and XEf^iX nodes. The extended protocols contain 
the core protocols as a subset. See Figure 2 for an 
illustration. The core and extended protocols are in 
public domain and can be implemented under other 
operating systems, thus enabling a host of otherwise 
incompatible systems to share data and resowces 
and to communicate across the network. 



NETWORK HIERARCHICAL FILE 

SYSTEM 

The file sharing protocols Implemented in a network 
extend the file systems of the individual nodes into a 
so-called network hierarchical file system. Within a 
network any user can access each of the "public" 
files through a unique path of the network directory. 
For an illustration of the latter, please refer to Figure 
3. Note that a directory can be designated as public 
(accessible from other nodes of the network) or pri- 
vate (accessible only locally) when SYSGEN-ing the 
server. Within a network hierarchical file system the 
same access right options are available as under 
RMX 86, that is a remote file can be r^ only, writ- 
ten into or searched dependr^ on tiow it is set up. 



IMPLEMENTATION 

iRMX-NET implements file access across the net- 
work through Introducing a new file type, the "re- 
mote file." The IRMX operating system originally 
supports physical, stream and named files through 
the respective file drivers contained within the Basic 
I/O system (BIOS). iRMX-NET adds a new file driver 
called remote file driver (RFD). All local commands 
rtefered^ng r^iTiQto files are intercepted at the BIOS 
level arid are retfrected through the RFD to the net- 
work. 



VIRTUAL ROOT 



SYS. A 
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SYS. C 







Figure 3. Network Hierarchical File Sy^Mn 
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The server receives the command from the network 
and forwards it to the local operating system acting 
as a user for the local file system. For an Implemen- 
tation block diagram please refer to Figures 4 and 5. 

TTw bonsuntty eamieiitef iMtol^^ building blocks. 
The RFD-h vpmXm sysMK'tfepmdeRt mm 
be oKrfiguted to rurt under ttw thtat The fSe con* 
sumer biMtia l^ock is aipported by the s|i^W^ 
eculive of INA 960 and can rurf a sd{winEm%n®<t^ 
essor along with iNA 960. 

The server includes a file server building block and a 
name server module which are configured to run 
with iNA 960 and are operating system independent. 
The server interfaces to the host operating system 
through the File Access interface which runs under 
the host operating system. 



NAME SERVER 

The Name Server provides name to network ad- 
dress mapping for the users. iRMX-NET implements 
a distributed or "protocol t»8a#' name aeiVar 
scheme in which every node "knows" Its own none 
and address and thus lhere is no "iT»8ter directoiy" 
Mi within the system; ' ' ' 

When a user is referendng a MMtte nodif on the 
network by its name the file consumer broadcasts a 
request for that name across the network. The only 
node having the name called will respond tjy send- 
ir^ ^ ilddidss to file requestor. 
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Figure 4. IRMX-NET File Consumer Implementation 
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SYSTEM ENVIRONMENT 

(RMX-NET is supported by any system in which 
iRMX 86 Is at release level 6.0 or later and in which 
the iNA 960 transporl^ftware j8«lres^ eof^MFsd 
in. 

iRMX-NET is included at sysgen time as a first level 
job if the extended I/O system Is not present or as 
an I/O job If it is present. iRMX-NET contains a num- 
ber of user-defined parameters which must be set 
up when configuring the system, These parameters 
Include the size of buffers, the number of consumers 
served concurrently or the ma)toum p»{IUSSlble 
number of outstanding processes. 



remote and local files alike. As a file server to a DOS 
consumer, IRMX-NET functions just like a PG AT file 
server. As a server to XENIX consumer there are a 
few limitations to transparency, for example, the 
"LOCK" and "LINK" XENIX commands are not sup- 
ported under IRMX. As a file consumer to a XENIX 
server IRMX-NET provides full transparency. 



SPECIFICATIONS 

— Code size: about 40 KB 

— System requirements: - RMX 86 R6.0 or later 

-iNA 960 

— Throughput: T. B. D. 



USING IRMX-NET 

When first referencing a remote directory the user 
has to issue an "attachdevice" command just like in 
the case of attaching a new local device under RMX 
86. For example If the remote system is SYSB the 
user will need to issue the following CQfXIIWSt 

Attachdevice SYSB as :f5: Remote. 

In this case :f5: Is chosen to designate the newly 
opened "network volume." The "attachflle" com- 
mand In fact opens a virtual circuit between the con- 
sumer and the server to support the subsequent 
communication between these two nodes. Once the 
rpTiote device is "attached" the user can access his 



ORDERING INFORMATION 

iRMX-NET WRO 

Object code on double density RMX diskettes 
with OEM license. 

iRMX-NET WSU 

Object code on double density RMX di^^s 
with single user development license. 
iRMX-NET LST 

Source listing on microfiche. (Available for R1.1 
and up.) 

iRMX-NET SRC 
Machine readable source 
(Available for R1.1 and up.) 
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Figure 5. RIe Server Implmnentation 
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XENIX* NETWORKING SOFTWARE 

MEMBER OF THE OpenNET PRODUCT FAMILY 



■ Transparent Network File Access 
Allows Existing Applications to be 
Distributed without Change 

■ Interoperation between IRMXTm, XENIX 
and MS/DOS* Based Systems over a 
Local Area Network (LAN). 

— Interoperation between XENIX and 
DOS by Rel 1.0 

— interoperation between XENIX and 
IRMXbyReil.l 



■ Runs under XENIX 3.0 on 286/310 and 
286/380 Systems 

■ Supports OpenNETTM Hardware and 
Software 

— iSXIVITM 552 Ethernet COMMengine 

— INA 961 Tran^MTt Software 

■ SupporfiB Ftte Server Apptl^ions 



XENIX Networking software is a part of Intel's OpenNET Product Family wtiicti provides transparent file access be- 
tween IRMX, XENIX and MS/DOS systems across a LAN. Users can use local file systems commands to read, write, 
open, close, etc. files residing at remote IRMX, MS/DOS and XENIX systems. Ttie XENIX Networking Software im- 
plements the upper layer protocols used by Microsoft Networks, Interoperation among ttiese systems is supported 
by Intel's OpenNET LAN product line Including the iSXM 552 Transport Engine, INA 961 (a preconfigured version of 
INA 960 transport software), the iSBC® 186/51 COMMputer™ and the INA 960 Transport software. Networked 
XENIX systems serve in a wide range of applications, such as distributed data processing, devetopment. scientific 
and engineering applications, and graphics. Below is a diagram &f the OpenNET Local Area Network. 




231380-1 



' XENIX and MS/DOS are trademarks of Microsoft Corporation. 



Intel Corporation assumes no responsibility for the use o* any circuitry other than circuitry emtiodled in an Intel product. No other circuit patent 
licenses are implied, informata contained tmem supersedes previously published spedficatlisns on these deytcra from IMel. Frimjary IMS 
® Intel Corporation, 19S5 
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XENIX— NETWORiaNQ* 
DESCRIPTION 



The )CE.HEK M^working software provides transpar- 
ent remote file access ea^ibi% Vnmi^ siit^&m' 
sumer fflid a fUa server nocye. the otnaiMer If^ 
cepte file oonvnan^'fram the tetri user application 
and transmits iWBtii acrora the LAN to the server at 
a network system or ngde: wtere the target file re- 
skJes. The server recess, interprets, and executes 
the command acting as a user to its local file sys- 
tem. The user has the option of configuring either or 
both the consumer and server In his target system. 

The XENIX Networking Software also Includes a 
name server which allows a logical name to be used 
to refer to remote nodes instead of the physical LAN 



The capabilities allow XENIX systems to interoper- 
ate over the LAN with RMX systems (with release 
1.1) configured with RMX Networking software or 
MS/DOS systems (with release 1 .0) using Microsoft 
Netwc(^. This Interoperatlon ents^aGS^ssing data 
and loading programs through the nehvork, sharing 
common servers, and communication between 
users. 

The XENIX Networking Software requires the su|)- 
port of an underlying ISO 8073 compatible transport 
service provided in the INA 960 network software 
running on the iSXM 552 Transport Engine. In terms 
of tfie l$0 reference model. ft^lpMt^ 



tbi. cortjunctlon with the transport servk^ and Ether- 
n« heirdwrare provides complete seven layer func- 
tionality and serves as the fundammtal buttdng 
block for the development of other services su^ as 
frnU ^ tom^ emiei^oa (see Figure 1 ). 



TRANSPARENT REMOTE FILE 
ACCESS 

XENIX Networking provides transparent remote file 
access at the application Interface level. This means 
that all XENIX 3.0 applications written using operat- 
ing system file access commands can be used with- 
out change In a networked environment where the 
referenced files may reside at other nodes of the 
network. 

With release 1.0 of the XENIX Networking aollware, 
the user (file consumer) can trttfis^ventty access 
files resident at remote systMiUl 'eonfigUtSiti vtlttt 
XENIX or MS/DOS file senders. \Nrm% 'mm m 
server supports remote nodes configured viMi both 
XENIX and Microsoft Networks and file consumers. 
For a table showing the combinations supported 
with the initial OpenNET product line, please r^er to 
Figure 2. 

Transparent remote file access enables the user to 
manipulate and use remote files as if they were lo- 
cal. This capability is used for key network services, 
such as mail, print server, and remote execution on 
Other XENIX nodes. 

Ml-, ir-i ...f J.,:-: >{■■ ^-yj- — ■ — ■ 
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Figure 1. OpenNET™ Product Offerings 
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Figure 2. Interoperation 



NETWORK FILE ACCESS 
PROTOCOLS 

File sharing among different operating systems 
across tfie network Is made possible through imple- 
menting a common set of file access (or file sharing) 
protocols under these operating systems. Network 
file sharing protocols are a set of rules governing the 
interaction between a file consumer and a file server 
on the same local area network. The file access pro- 
tocols used by the OpenNET product line were joint- 
ly developed by Intel, Microsoft, and IBM. 

Since the file systems of DOS, XENIX, and iRMX are 
not identical, two protocol sets have devised to sup- 
port transparency in the various server-consumer 
combinations. The core protocols support transpar- 
ent flte access between a MS/DOS consumer and 
remote server. The "extended protocols" support 
transparent file access between RMX and XENIX 
nodes. The extended protocols contain the core pro- 
tocols as a subset. See Figure 3 for an illustration. 



The oe>re and extended protocols are in public do- 
main and can be implemented under other operating 
systems, thus enabling a host of otherwise incom- 
patible systems to share data resources and to com- 
municate afscoss, the network. 
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Figure 3. Nefwrork Rle Access Protocols 



NETWORK HIERARCHICAL FILE 
SYSTEM 

The file sharing protocols implemeted in a network 
extend the file systems of the individual nodes into a 
hierarchical file system. Within a network any user 
can access each of the "pubtic" files through a 
unique path of the network directory. For an Illustra- 
tion of the latter, refer to Figure 4. Within a network 
hierarchical file system the same access right op- 
tions are available as under XENIX 3.0, that is a re- 
mote file can be read only, written into or searched If 
the requesting user has the appropriate permissions. 



NETWORK 




Figure 4. Nelhiirork Htarareliieal File System 
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Figure 5. XENIX Networking Consumer/Server 



IIVPLIMENTATIOM . 

The XENIX Networking software implements file ac- 
cess across the network through enhancing the file 
naming syritE^, The logical name associated with a 
remote system (or nocfe) is appended by the user to 
the path name trf the required -file. This rfotnehetaf- 
ture is diistfhEltfishfed fwm mormai path names by a 
double slash (//). A simitar technique is used for 
IVIS/DOS arvd RMX. 



// < node name > / < path name 

Hooks have been imbedded in the standard XENIX 
3.0 Operating System offered by Intel which detect 
remote file accesses. XENIX Networking consists of 
a consumer task and server task. All local com- 
mands referencing remote =§68 are intercepted at 
the kermel m<i arate^Med throuf h ttie ewr 
sumwsotew»«t9 t»e ntawM*;. ' 

The 8©i«vef sofWafe recdfveSlh© command from fh* 
network and forwards it to the local operating S0i>- 
tem acting as a user for the local file system. For art 
implementation block diagram see Figure 5. 

The consumer includes a name server module 
which is configured to run with the iNA 961 Trans- 
port Software and is operating system independent. 
The name server accesses a local file which keeps 
track of valid node names and their physical LAN 
address. 



SYSTEM ENVIRONMENT 

The XENIX Networking software can be used on any 
system running Intel's XENIX 3.0. This includes the 
^!'>ft9 aA<l ?8f /^80 ?)fStetT^. ?ince networking 
"me^'S»& sil^<ctflH^ii^ in ttie operating sys- 
tem nothing other than loading the XENIX Network- 
ing software onto the local system is necessary. 
Special network utilities are included for building and 
maintaining the network configuration files so that 
the network can be tailored to meet each customers 
needs. 

The network supports a single community of users 
which means that a user name is unique across the 
network and therefore users can log-in at any sys- 
tem on the network. 

File security is provided by the standard XENIX 3.0 
file protection of owner, group, and other access. A 
local node can restrict local access for remote users 
1^ atowlng all, none, or a selected few remote 
nod^. 



USING XENIX NETWORKING 

When the networking software and configuration 
files are located in each node, all each node has to 
do is start the consumer and/or start its server to 
make its files available to other network systems to 
start referencing remote files immediately. Each 
node can tatk to as many as 20 other nodes at 
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the same time. This is dynamic and a node can 
switch to any other nodes at any time as long as it 
doesn't exceed 20. This limit is only for consumer 
tasks talking to server tasks and vice versa and in no 
way limits the number of users at a node which can 
liave remote file access, i.e., all user requests from 
a single node are multiplexed through a single 
consumer. 

The standard XENIX 3.0 mail works via XENIX Net- 
working across the I^N as well as remote execution 
on XENIX 3.0 systems via the AT command. 

As a consumer to RMX servers there are a few limi- 
tations to transparency, for example, the "LOCK" 
and "LINK" XENIX commands are not supported 
under RMX. As a file server to a RMX consumer, 
XENIX Networking does provide full transpar^tey. 



ORDERING INFORilATKm 



SPECIFICATIONS 

—Code size: 



—about 60 KB 
plus 40 K for buffers 



— System requirements— XENIX 3.0 
— INA 961 

— XENIX Networking along with the INA 961 soft- 
ware and the iSXM 552 have been qualified ^r 
the 286/31047. 2i6/3l0-41. and 286/380 
tems. 



XNX-NET-NSO 



XNX-NET-961-NSU 



XNX-NET-KIT-NRI 



XNX-NET-RO 



XNX-NET-RF 
XNX-NEr-l«l 



iNA-961-RO 
iSXMSS2 

SYS 31 0-41 XN 
SYS310-17XN 



iMDX 457 
iMDX 3015 
iMDX 3016-1 
IDCM 911-1 



XENIX Networking Software 
(both 8 " and 5 Vt " double sided, 
double density) plus rights for 
eight copies 

XENIX Networking and INA 
961 Object Software (both 8" 
and SVi" double sided, dou- 
ble density) plus rights for 8 
copies 

XENIX Networking and INA 
961 Object Software (both 8" 
and sy^" double sided, dou- 
ble density) plus ISXM 552 
Transport Engine for pass 
through use 

XENIX Networking and INA 
961 Object Software (both 8" 
and SYi" double sided, dou- 
ble density) plus license rights 

Software Incorporation Fee 

Machine Readable source 
code for the XENIX Network- 
ing Software, (both 8" and 
SVi" double sided, double 
density) 

INA 961 Transport Software 
plus license rights 

Ethernet Transport Engine 
plus one INA 961 Software In- 
corporation Fee 

XENIX System 286/310-41 
with Xenix Networking Soft- 
ware, iNA961 Transport Soft- 
ware and ISXM 552 Transport 
Engine 

XENIX System 286/310-17 
with Xenix Networking Soft- 
ware, INA 961 Transport Soft- 
ware and iSXM 552 Transport 

Engine 

Ethernet Transceiver Cable 
Ethernet Transceiver 
Ethernet Cable 

Intetlink™ 



Ethernet hardware and software for the IBM Person- 
al Computer Is available from Ungermann Bass, Inc. 
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OpenNET™ 
Personal Computer Link 



Connects an IBM* PC AT, PC XT (and 
PC-DOS Compatible^ to tile OlpenNET 
Network 

Works With Standard DOS Commands 

Interconnects a PC System to HFfMX^^ 
XENIX*, and NDS-li/NRM Systems 
Offering OpenNET Server Capability 

Uses an 80186/82586 Processor-taaedi 
Network Controller Board 

Supports the ISO/OSI Seven Layer 
Networking Standards 



■ Enables a PC System to Access Remote 
Storage and Printer Devices 

■ Provides Transparent-flle-access 
Capability Between a PC Syslem and 
Remote Servers 

m Contains Power-up Diagnostics 

■ Uses ISO 8073 Transport and 
Ethernet/IEEE 802.3 Standard 
Communication Protocols 



The OpenNET Personal Computer Link (OpenNET PC Link) enables users to eennfleftlieif IBM PC AT and PC 
XT computer systems to the OpenNET network. This connection enables a PC system to be configured as a 
consumer workstation on the OpenNET network, and to transparently access and share files and printers on 
an OpenNET network resource manager (NRM), NDS-II (with the OpenNET upgrade installed) NRM, IRMX, 
and XENIX-based remote server systems. The OpenNET PC Link is an 80186/82586 microprocessor-based 
expansion board, which is easily installed in an expansion card slot of the PC system. On-board jumpers and a 
user configurable software package enable the OpenNET PC Link to be used with a wide-range of expansion 
boards currently available for the PC system. The OpenNET PC Link Incorporates the Mlcrosott' Networks 
(MS-NET) networking software and iNA 960 (ISO 8073 compaHble) transport software as a part of Itssoftwwe 
package. 






*IBM is a registered trademark of the International Business Machines Corporation. 

'XENIX is a trademarit of the fvlicrosofi Corporation. 

'Microsoft is a registered trademarl( of the Microsoft Corporation. 

Intel Corporation assumes (M)Mf8lifll$ lerMtif^of any circuitry other than circuitry embodied in an Intel product. No other circuit patent 
licenses are impBed. ln to WWiig|»WTOWtilBjl»l>w previously published specifications on these devices Horn Intet. " ' 



© Intel Corporation, 1985 
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OpenNET™ PC Link 



PRODUCT OVERVIEW 

The OpenNET PC Link is a member of Intel's Open- 
NET networl<ing product family. The OpenNET prod- 
ucts incorporate a set of system and component 
level LAN products covering all seven layers of the 
ISO (International Standards Organization) Open 
System Interconnect (OSI) model, and the protocols 
on which they are based. OpenNET network proto- 
cols are established industry standards for each 
function. Therefore, OpenNET network products 
can connect and operate not only with each other, 
but with the most popular networking products from 
other vendors. OpenNET networks provide a high 
level of interoperability between heterogeneous sys- 
tems (MS-DOS', PC-DOS, INDX, XENIX, and iRMX 
operating system versions are available). Thus, us- 
ers can tailor their networks to meet their specific 
needs by incorporating any combination of tlie capa- 
bilities of these diverse systems. 

The OpenNET network application protocols imple- 
mented by OpenNET PC Link software are those 
adopted by Intel, Microsoft, and IBM for their com- 
puter networking products. The OpenNET PC Link 
software is compatible with and will operate with 
INDX, XENIX, and iRMX natworldng softwarv at tti& 
application layer. 



PHYSICAL DESCRIPTION 

The OpenNET PC Link consists of a network control- 
ler board and a 5-1/4 incfi disk that contains the soft- 
ware necessary for the PC system to communicate 
across the OpenNET network. The folkwing seo- 
tk>ns describe the hardware and software compo- 
nents of the OpenNET PC Link. 



OpenNET^" PC Link Network Controller 
Board 

The network controller board is an adaptor board 
that can be installed in any available expansion slot 
of a PC system. The board implements the industry 
standard ISO 8073 transport protocol (a modified 
version of INA 960) and Ethernet/IEEE 802.3 physi- 
cal data link technology (see Figure 1). The board 
uses an Intel 80186 microprocessor in combination 
with an 82586 LAN communication controller. The 
board includes the following major components: 

• 80186 microprocessor 

• 82586 LAN oommunlcations conbioUer 

• SKBofEPROM 

• MS-DOS is a trademark of Ow Microsoft Corporation. 



• 128 KB of RAM shared between the PC system 
and the 80186 microprocessor on the network 
controller board 

• 82501 Ethernet serial interface 

• Fujitsu MB502A encoder decoder 

• 15-pin Ethernet D connector 

• 8-bit parallel DMA interface and control register 
set 

• Power-up diagnostics 

The network controller board performs all network 
communication functions for the first two layers of 
the ISO/OSi model (see Figure 2). Layers three and 
four reside in the modified INA 960 transport soft- 
ware. The remaining layers (five through seven) re- 
side in the MS-NET networking software on the PC 
system. 



POWER-UP DIAGNOSTICS 

An effective diagnostic function is Implemented in 
firmware on the network controller board. This func- 
tion is invoked at system initialization during both 
power-up and system reset time. The following list 

summarizes the functions tested: 

• 80186 and 82586 microprocessors 

• I/O ports 

• Shared memory window 

• Interrupt channels 

• DMA channel 

• Ethernet connection 

An on-board LED indicates whether the network 
controller board failed any of the various test func- 
tions. 



OpenNEr" PC Link Software 

The software is supplied on a 5-1/4 inch 
double-density disk (360 KB). The following files are 
included as part of the OpenNET PC Link: 

• A specially configured version of iNA 960 trans- 
port layer software, called UBCODE.MEM, which 
operates on the network controller board. 

• A DOS interface driver, called XPORTEXE, 
which enat>ies DOS programs to accras the net- 
work 6onW)ner board. 

• The Microsoft Networks (MS-NET) networking 
software, release 1.0, which enables users to 
connect with and access remote file servers on 
the OpenNET network system. 
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OpenNET^M PC Link 
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Figure 1. The OpenNET^M PC Link Environment 
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Microsoft Networks Software 

The Microsoft Networks (MS-NET) networking soft- 
ware is included as part of the OpenNET PC Link 
software. The MS-NET software manages the trans- 
fer of information between the PC system and a re- 
mote server Once a connection is made between 
the PC system and a remote server or printer, the 
user uses the MS-NET software (in conjunction with 
DOS commands) to access and manipulate remote 
files or printers. Table 1 presorts A list of MS-NET 
commands and a description of each command. 

The MS-NET networking software displays a mes- 
sage each time a command is successfully com- 
pleted. If an error is made, the software displays an 
error message listing the probable cause of the error 
and suggestions for correcting it. On-line help files 
enable the user to quickly reference MS-NET com- 
mands and obtain the correct syntax for entering 
commands. 

OpenNET™ PC LINK SPECIFICATIONS 
Host Requirements 

IBM PC AT or PC XT computer system 

— 1 92 KB of system memory 

— DOS (MS-DOS or PC-DOS) operating system, 
version 3.1 or later 

Physical Chiaracterlstics 

NETWORK CONTROLLER BOARD 

Width: — 13.315 in (33.82 cm) 
Height — 4. 15 in (10.54 cm) 
Weight — 35 oz (.99 kg) 



SOFTWARE 

5-1/4 inch dCtietbie-densfty disk (380 KB) 

POWER REQUIREMENTS 

-1-5 volts at 2.7 Amps 
+ 12 volts at .5 Amps 



ENVIRONMENTAL CHARACT0)ISTICS 

Operating Temperature — 0° to 85 "C (32° to 
131 °F) 

OperaUng Humidity — Maximum of 90% relative 
humidity, non-condensing 

Convection oooHrtg 



DOCUMENTATION 

1 65996 OpenNET'^ PC Link User's Guide 



Optional Equipment 

The following items can be ordered for use with the 
OpenNET PC Link: 

PCLNK20F Transceiver cable, 20 ft 

(18.29m) 

PCLNK164F Transceiver cable, 164 ft (50 m) 

DCM911-1 Intellink module 

iMDX301 5F Transceiver 



ORDERING INFORMATION 

PCLNK OpenNET PC Link: Consists of a 

network controller board, a PC XT card 
support, software, and a user's guide 



INTEL CORPORATION, 3065 Bowers Avenue, Santa Clara, California 95051 (408) 987-8080 
INTEL CORPORATION (U.K.) Ltd., Swindon, United Kingdom; Tel. (0793) 696-000 
INTEL mPm k-k., tearaki-ken; Tel. 029747-851 1 
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Figure 2. ISO/OSI OpenNET™ PC Link Implementation 
PC SYSTEM REQUIREMENTS 



For the PC system ^ nmnsmva a m^ss&mn m 
the OpenNET network, lr iniist <eontiM m ism ^ 
KB of memory. A 32 KB nmrneiy wteidM Id ^liief^ 
between the PC system an6 iAm mtm«»^ m«iMlm 
board. The starting address of 8iis window must be 
placed in an >area of m^ndty ^ does tmeemfki 
with the PC system's intemal mmmf mioms 
space. The network controller board is junqsiered at 
the factory to r^lsct a setting whidi is compatible 
with the PC system and most of the expansion 
boards available for use with the PC sfs^m. 

In oRler for the rietwork rasritroller |tl^|rd ajnlt the 
OpenNET software to function pfQpe^ J^Jp 
tem mu^ use the DOS (MS-DOS or Ri-I^Qi^ oper- 
ating system, version 3.1 or later. 



FUNCTIONAL DESCRIPTION 

The OpenNET PC Link enables a PC system to be 
configured as a consumer workstation in the Open- 
NET network environment. This enables a PC sys- 
tem to access and share files and remote printers on 
a remote file server. After establishing a connection 
with a remote server, the user can access different 
directories by connecting drive letters at the PC sys- 
tem to the desired directories. 



Creating a PC System Consumer 
VMtriffitatlon 

The PC system is easily configured as a (»nsumer 
workstation on the OpenNET network. The following 
mfammima^ttm^4^m<M§!utB the PC s^m for 

• Install the OpenNET PC Link network controller 
board in the PC system and connect the PC sys- 
tem to an Ethernet transceiver or Intellink™ mod- 
ule. 

• Configure the OpenNET PC Link software to re- 
flect the name and network address assignefl to 
the PC system and each remote server system 
that the PC system will access. 

• Define the i% sysHBRi user as a valid user of the 
remote server sy^sm. 

To connect witti and scces remote resources over 
the QpenNKiRMMic, perform the following steps: 

f .^vjelsp 1^ s^^tsm's consumer networking 
softWarfe. ^ 

• Execute a connect-to-server commarid. 

• Execute standard DOS commands. 

The PC system user can now access remote re- 
sources (files, directories, or printers) at remote serv- 
ers on the network. 
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OpenNET™ PC Link 



The user has the option of automatically connecting 
to a remote server each time the DOS operating sys- 
tem Is booted. This is done by placing networking 
commands in a DOS AUTOEXEC.BAT file. 



Remote Server Access 

The PC user gains access to a remote server by con- 
necting an unused drive letter at the PC system to a 
remote home directory at the server The server vali- 
dates the PC system user by comparing the user 
name offered in the connect-to-server command 
with the server's user definition file. If the name is 
valid, the user is logged on to the server, and can 
access any file within the home directory. Multiple 
subdirectories may be created within the home di- 
rectory. The user is restricted from accessing direc- 
tories or files located above the user's home 
directory. 



D-ansparent Access to Multiple 
Directories 

A PC system user may access multiple directories at 
a file server This is done by defining multiple users 
(giving users access to different directories) at the 
server After establishing a connection to the server, 
the user can access different directories by connect- 
ing drive devices at the PC system to the desired 
directories. 



Data and resource sharing are implemented via 
transparent remote file access. This enables the 
user to work with remote data files and resources 
residing at server systems on the network as if they 
were resident on the PC system. Users of a remote 
server may be given access to the same home direc- 
tory, enabling multiple users to access and share re- 



mote data files. The access rights of remote data 
files can be changed to enable all or some of the 
users to read, write, or delete files in that directory. 



Using DOS Commands Across the 
OpenNET™ Network 

Once the PC system has been connected to a re- 
mote server on the network, almost any DOS com- 
mand can be used with remote files and directories. 
The exceptions are commands that manage physi- 
cal devices (e.g., FORMAT). The MS-NET software 
reports an error message if an invalid DOS com- 
mand is sent across the network. Using DOS com- 
mands, the user can manipulate drives, files, and 
directories as follows: 

• Look at and list remote directories and files 

• Copy files back and forth between a PC system 
and a remote server 

• Redirect print requests to a remote printer 

• Set and reset the read-only attribute of remote 

directories and files 

• Map drive assignments to remote directories 

• Set the path to remote directories and files 

Shared Printer Access 

The PC system can be linked to a remote printer that 
is connected to a server on the OpenNET network. 
This enables the user to take advantage of the re- 
mote printer services, thus freeing the user from 
having to install a printer at the PC system. 

A PC system user can print local or remote data files 
by first connecting the PC system's logical printer 
device to the remote server's printer spool. Then, the 
MS-NET networking software command NET PRINT 
is used to print the file on the remote printer device. 



Table 1 . MS-NET Networking Commands 



Command 


Description 


APPEND 
NET CONTINUE 
NET HELP 
NET NAME 
NET PAUSE 
NET PRINT 

NET START REDIRECTOR 
NET USE 


Locates a file which is outside the current directory. 

Restarts the disk redirector or print redirector programs. 

Displays a help file with information about M&44Et eenmnands. 

Displays the name assigned to your PC system. 

Temporarily halts the disk redirector and print redirector programs. 

Prints a file on a remote printer. 

Invokes the OpenNET PC Link consumer networking software. 
Connects a device at the PC system to a reniote server or printer. 
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